-
Notifications
You must be signed in to change notification settings - Fork 793
[SYCL] Allow _Bitint of size greater than 128 bits when -fintelfpga i… #6152
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a CodeGen test to ensure IR is generated as expected for 128 bit?
@@ -2306,7 +2306,7 @@ QualType Sema::BuildBitIntType(bool IsUnsigned, Expr *BitWidth, | |||
} | |||
|
|||
const TargetInfo &TI = getASTContext().getTargetInfo(); | |||
if (NumBits > TI.getMaxBitIntWidth()) { | |||
if (NumBits > TI.getMaxBitIntWidth() && !Context.getLangOpts().IntelFPGA) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't there be some code handling the larger size for this target? Is just removing the error enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it is enough. The actual handling is done by the backend or via library calls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this is not enough. We need to make sure we don't emit anything too large for the LLVM backend.
IMO, the RIGHT place for this is probably to get the proper target-info for the FPGA to change its answer to 'getMaxBitIntWidth' based on the FPGA status to the LLVM max value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this is not enough. We need to make sure we don't emit anything too large for the LLVM backend.
IMO, the RIGHT place for this is probably to get the proper target-info for the FPGA to change its answer to 'getMaxBitIntWidth' based on the FPGA status to the LLVM max value.
If we go with this way in any following patch, 2048 is a reasonable upper-bound limit for the FPGA target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify: My concern is this: https://llvm.org/doxygen/classllvm_1_1IntegerType.html#af13295ff815293f6c5708ebdbae1338da1ccefdf8a7414a6829f888e5071e0379
if there is a reasonable max for the FPGA target, we should definitely do that too.
I have added one for the host and one for the device. These are just rudimentary tests to see that nothing crashes; they are not meant for comprehensive testing of all _BitInt operations. |
@Ralender this is to generalize. |
When I tested >128 BitInt division with sycl/rel to bypass this err_bit_int_max_size diagnose in sycl/trunk, I got another error - "Unsupported library call operation!" in the So I wonder if this error still exists in sycl/trunk and needs to be handled in this patch as well? I cannot verify this myself, because the err_bit_int_max_size diagnose in the |
Do you have a test case that shows the error above? I can verify that with the current sources and my patch. |
Thank you :) I can upload my test case to the Jira.
|
I am moving this PR to draft status until the post-link errors reported by @shuoniu-intel are resolved. |
These appear to be resolved now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok for Driver
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
@intel/llvm-gatekeepers, this is ready for a merge. |
@@ -2306,7 +2306,7 @@ QualType Sema::BuildBitIntType(bool IsUnsigned, Expr *BitWidth, | |||
} | |||
|
|||
const TargetInfo &TI = getASTContext().getTargetInfo(); | |||
if (NumBits > TI.getMaxBitIntWidth()) { | |||
if (NumBits > TI.getMaxBitIntWidth() && !Context.getLangOpts().IntelFPGA) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change looks wrong to me -- LLVM has a max bit width size that we must ensure the user stays within the bounds of. Passing the intel FPGA flag won't make a bit of difference in that case, it'll just crash in the backend.
// is allowed when -fintelfpga is enabled. | ||
|
||
// CHECK: define{{.*}} void @_Z3fooDB211_S_(i211* {{.*}} sret(i211) align 8 %agg.result, i211* {{.*}} byval(i211) align 8 %[[ARG1:[0-9]+]], i211* {{.*}} byval(i211) align 8 %[[ARG2:[0-9]+]]) | ||
signed _BitInt(211) foo(signed _BitInt(211) a, signed _BitInt(211) b) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good test, now try it with _BitInt(123456)
. Do the results still seem reasonable? (Basically, we should be testing the edge cases much more heavily than we seem to be doing.)
It seems this was merged before I could post my comments -- please address them in a follow up (or revert if the follow up is going to take significant time). |
Thanks for the comments @AaronBallman and @erichkeane. I will revert it for now and then reapply the changes you suggest. |
Let me handle the revert for you. |
See #6232. |
…s used (#6295) This revives the patch for #6152 (which was reverted in #6232). In this patch, the new change is that there is a new target for spir64_fpga and the maximum bitsize limit for that target is 2048. Unfortunately, for the host, there is now an explicit check in Sema for the same bitsize. When -fintefpga is specified with -fsycl, we allow a maximum bitsize of 2048.
…s used