Skip to content

[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

Merged
merged 5 commits into from
Jun 2, 2022

Conversation

premanandrao
Copy link
Contributor

…s used

@premanandrao premanandrao requested review from a team as code owners May 13, 2022 17:37
Copy link
Contributor

@elizabethandrews elizabethandrews left a 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) {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

@premanandrao
Copy link
Contributor Author

Can you add a CodeGen test to ensure IR is generated as expected for 128 bit?

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.

@keryell
Copy link
Contributor

keryell commented May 13, 2022

@Ralender this is to generalize.

@shuoniu-intel
Copy link
Contributor

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 clang++ -cc1 -triple x86_64-unknown-linux-gnu ... compile of the non-emulation flow and in the opencl-aot ... compile of the emulation flow. However, I don't see such diagnose string in DiagnosticSemaKinds.td.

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 clang++ -cc1 -triple spir64_fpga-unknown-unknown ... compile currently blocks any later diagnoses in sycl/trunk.

@premanandrao
Copy link
Contributor Author

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 clang++ -cc1 -triple x86_64-unknown-linux-gnu ... compile of the non-emulation flow and in the opencl-aot ... compile of the emulation flow. However, I don't see such diagnose string in DiagnosticSemaKinds.td.

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 clang++ -cc1 -triple spir64_fpga-unknown-unknown ... compile currently blocks any later diagnoses in sycl/trunk.

Do you have a test case that shows the error above? I can verify that with the current sources and my patch.

@shuoniu-intel
Copy link
Contributor

Thank you :) I can upload my test case to the Jira.

Do you have a test case that shows the error above? I can verify that with the current sources and my patch.

@premanandrao
Copy link
Contributor Author

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.

@premanandrao premanandrao marked this pull request as draft May 16, 2022 15:15
@premanandrao premanandrao marked this pull request as ready for review June 1, 2022 17:27
@premanandrao
Copy link
Contributor Author

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.

Copy link
Contributor

@mdtoguchi mdtoguchi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok for Driver

Copy link
Contributor

@smanna12 smanna12 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@smanna12 smanna12 requested a review from elizabethandrews June 1, 2022 17:50
@premanandrao
Copy link
Contributor Author

@intel/llvm-gatekeepers, this is ready for a merge.

@bader bader merged commit 51f2ea3 into intel:sycl Jun 2, 2022
@@ -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) {
Copy link
Contributor

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) {
Copy link
Contributor

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.)

@AaronBallman
Copy link
Contributor

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).

@premanandrao
Copy link
Contributor Author

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.

@bader
Copy link
Contributor

bader commented Jun 2, 2022

Let me handle the revert for you.

bader added a commit that referenced this pull request Jun 2, 2022
@bader
Copy link
Contributor

bader commented Jun 2, 2022

Let me handle the revert for you.

See #6232.

pvchupin pushed a commit that referenced this pull request Jun 23, 2022
…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.
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.

9 participants