Skip to content

[SYCL] Add Clang support for FPGA loop fusion function attributes #2876

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

elizabethandrews
Copy link
Contributor

This patch adds support for FPGA function attributes loop_fuse and
loop_fuse_independent. [[intel::loop_fuse(N)]] is a strong request,
to the extent possible, to fuse loops within the function, that are
contained in at most N-1 other loops within the function. If the
optional parameter N is omitted, it is a strong request, to the extent
possible, to fuse loops within the function that are not contained in
any other loop within the function. [[intel::loop_fuse_independent(N)]]
is used to guarantee that fusion safety analysis can ignore
negative-distance dependences between these loops.

FrontEnd Specifications:

The attributes take one optional parameter, a constant integral
expression between 0 and 1024*1024. The paramter may be a template
parameter.

The same function definition can have atmost one of these two attributes.

The attributes can be applied explictly to kernel. However, attributes
should not be propagated to callers i.e it should not be propagated from
device functions to kernel.

LLVM IR is function metadata as follows:

define i32 @foo() !loop_fuse !0
!0 = !{i32 N, i32 D}

where N is the value specified by the optional attribute argument. If
the optional argument is omitted, N is set to 1. D is equal to 0 for
[[intel::loop_fuse]] and 1 for [[intel::loop_fuse_independent]].

Signed-off-by: Elizabeth Andrews [email protected]

This patch adds support for FPGA function attributes loop_fuse and
loop_fuse_independent. [[intel::loop_fuse(N)]] is a strong request,
to the extent possible, to fuse loops within the function, that are
contained in at most N-1 other loops within the function. If the
optional parameter N is omitted, it is a strong request, to the extent
possible, to fuse loops within the function that are not contained in
any other loop within the function. [[intel::loop_fuse_independent(N)]]
is used to guarantee that fusion safety analysis can ignore
negative-distance dependences between these loops.

FrontEnd Specifications:

The attributes take one optional parameter, a constant integral
expression between 0 and 1024*1024. The paramter may be a template
parameter.

The same function definition can have atmost one of these two attributes.

The attributes can be applied explictly to kernel. However, attributes
should not be propagated to callers i.e it should not be propagated from
device functions to kernel.

LLVM IR is function metadata as follows:

  define i32 @foo() !loop_fuse !0
  !0 = !{i32 N, i32 D}

where N is the value specified by the optional attribute argument. If
the optional argument is omitted, N is set to 1. D is equal to 0 for
[[intel::loop_fuse]] and 1 for [[intel::loop_fuse_independent]].

Signed-off-by: Elizabeth Andrews <[email protected]>
@elizabethandrews
Copy link
Contributor Author

ClangFormat is failing on changes bought in through merge from intel/llvm, not my changes. How do I handle this @bader?

@bader
Copy link
Contributor

bader commented Dec 8, 2020

ClangFormat is failing on changes bought in through merge from intel/llvm, not my changes. How do I handle this @bader?

You can run clang-format (version 9.x) locally - e.g. using clang-format-diff script https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting

Another options is to download the patch CI system saves in artifacts and apply it as additional commit in this PR.
https://github.com/intel/llvm/pull/2876/checks?check_run_id=1519244214 - look for "Artifacts" in top right corner.

@elizabethandrews
Copy link
Contributor Author

ClangFormat is failing on changes bought in through merge from intel/llvm, not my changes. How do I handle this @bader?

You can run clang-format (version 9.x) locally - e.g. using clang-format-diff script https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting

Won't this create a commit with unrelated changes in this PR?

@bader
Copy link
Contributor

bader commented Dec 8, 2020

ClangFormat is failing on changes bought in through merge from intel/llvm, not my changes. How do I handle this @bader?

You can run clang-format (version 9.x) locally - e.g. using clang-format-diff script https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting

Won't this create a commit with unrelated changes in this PR?

It shouldn't not. The patch should fix formatting fir the diff between your branch and PR target branch i.e. for all commits in this PR and nothing else.

@elizabethandrews
Copy link
Contributor Author

ClangFormat is failing on changes bought in through merge from intel/llvm, not my changes. How do I handle this @bader?

You can run clang-format (version 9.x) locally - e.g. using clang-format-diff script https://clang.llvm.org/docs/ClangFormat.html#script-for-patch-reformatting

Won't this create a commit with unrelated changes in this PR?

It shouldn't not. The patch should fix formatting fir the diff between your branch and PR target branch i.e. for all commits in this PR and nothing else.

Hmm..I'm not sure if I messed up the merge somehow. The tests are failing because of a warning generated on code I didn't add. I think I'll just try opening another PR

@elizabethandrews
Copy link
Contributor Author

Replaced PR with - #2877

@elizabethandrews elizabethandrews requested review from AaronBallman and removed request for AaronBallman December 8, 2020 20:19
jsji pushed a commit that referenced this pull request Dec 14, 2024
This commit addresses issues with EnumClass handling in DebugEnumType.
In reverse translation, a bug caused the EnumClass flag to be incorrectly applied to every DebugEnumType with an UnderlyingType.
Additionally, in forward translation, the support for EnumClassFlag was missing entirely.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@50af2c70832745b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants