Skip to content

[SYCL] Allow _Bitint of size greater than 128 bits when -fintelfpga is used #6295

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 13 commits into from
Jun 23, 2022

Conversation

premanandrao
Copy link
Contributor

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.

@premanandrao premanandrao requested review from a team as code owners June 10, 2022 20:47
@premanandrao
Copy link
Contributor Author

@erichkeane and @AaronBallman, does this address the comments you had made in #6152? (Sorry that I am unable to continue the patch there.)

@@ -2305,10 +2305,21 @@ QualType Sema::BuildBitIntType(bool IsUnsigned, Expr *BitWidth,
return QualType();
}

const TargetInfo &TI = getASTContext().getTargetInfo();
if (NumBits > TI.getMaxBitIntWidth()) {
size_t MaxBitIntWidth = getASTContext().getTargetInfo().getMaxBitIntWidth();
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if instead we should be setting the aux-target in Host Mode to whatever the device triple is, and looking it up there? That would generalize this entire thing to : "if NumBits >TI.getMaxBitintWidth() && NumBits > AuxTI.getMaxBitIntWidth()"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Are you okay with this being done in a follow-up patch?

Copy link
Contributor

Choose a reason for hiding this comment

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

And should that change be happening upstream as well?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm a touch concerned as to the behavior changes we might get out of making this a part of the aux target (that is, accepting this and then doing the aux-target changes resulting in different behavior?). So I would at least want to see that patch be 'close' before accepting this.

@AaronBallman : While I think that is a GOOD idea (to set the aux target for host mode upstream), it doesn't help here since upstream doesn't have FPGA.

@shuoniu-intel shuoniu-intel requested a review from erichkeane June 21, 2022 19:30
@@ -2305,10 +2305,15 @@ QualType Sema::BuildBitIntType(bool IsUnsigned, Expr *BitWidth,
return QualType();
}

const TargetInfo &TI = getASTContext().getTargetInfo();
if (NumBits > TI.getMaxBitIntWidth()) {
// If the number of bits exceed the maximum bit width supported on
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm... I guess this would cause issues if the code is executed on the other platform, right? So we DO want to enforce the 'host' limit, but only if the 'host' bit-int gets emitted/used/etc? And vise-versa for the device? Or are we just hoping the failure is not quite silent later?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Or are we just hoping the failure is not quite silent later?

Right, I think that is what I was hoping. In this case we are in a configuration where one platform allows it but the other does not. Rather than preventing compilation here, I was relying on later phases catching it "nicely".

(In the specific case of intelfpga, which is where this can happen currently, there wouldn't be an issue later.)

Copy link
Contributor

Choose a reason for hiding this comment

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

That is incredibly unfortunate... We don't really have a good way of diagnosing with 'deferred diagnostics' on host unfortunately, so I suspect we're going to have to live with this.

erichkeane
erichkeane previously approved these changes Jun 22, 2022
@@ -2305,10 +2305,15 @@ QualType Sema::BuildBitIntType(bool IsUnsigned, Expr *BitWidth,
return QualType();
}

const TargetInfo &TI = getASTContext().getTargetInfo();
if (NumBits > TI.getMaxBitIntWidth()) {
// If the number of bits exceed the maximum bit width supported on
Copy link
Contributor

Choose a reason for hiding this comment

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

That is incredibly unfortunate... We don't really have a good way of diagnosing with 'deferred diagnostics' on host unfortunately, so I suspect we're going to have to live with this.

// RUN: %clang_cc1 -fsycl-is-device -verify=device -fsyntax-only %s
// RUN: %clang_cc1 -fsycl-is-host -verify=host -fsyntax-only %s

// Tests that we do not issue errors for _Bitints of size greater than 128
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we add a test where we do not diagnose since that is what this comment implies? I don't have strong preference since CodeGen tests test this anyway. So I leave it up to you.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I added the "passing" cases in CodeGenSYCL. I don't mind adding a case that would compile cleanly here. Is a value of 215 (greater than x86_64 limit of 128 but lower than fpga limit of 2048) okay with you?

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good to me

@premanandrao premanandrao dismissed stale reviews from elizabethandrews and erichkeane via d9df48b June 22, 2022 16:09
smanna12
smanna12 previously approved these changes Jun 22, 2022
@premanandrao
Copy link
Contributor Author

@hchilama, would you mind reviewing the driver changes while @mdtoguchi is on vacation? Particularly the changes in this change set ?

@premanandrao premanandrao requested a review from hchilama June 22, 2022 16:50
hchilama
hchilama previously approved these changes Jun 22, 2022
@premanandrao
Copy link
Contributor Author

@AaronBallman, are you okay with the new changes?

AaronBallman
AaronBallman previously approved these changes Jun 23, 2022
Copy link
Contributor

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

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

LGTM aside from a tiny nit (feel free to fix when landing).

Copy link
Contributor

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

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

LGTM

@premanandrao
Copy link
Contributor Author

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

@pvchupin pvchupin merged commit db5f72a into intel:sycl Jun 23, 2022
@pvchupin
Copy link
Contributor

@premanandrao, please address post-commit issues on windows: https://github.com/intel/llvm/runs/7029194202?check_suite_focus=true
Tagging @hchilama, seems problem is on drivers tests. I should probably give another chance to review driver changes. :(

@elizabethandrews
Copy link
Contributor

@premanandrao, please address post-commit issues on windows: https://github.com/intel/llvm/runs/7029194202?check_suite_focus=true Tagging @hchilama, seems problem is on drivers tests. I should probably give another chance to review driver changes. :(

Looks like it fails on Windows because test checks aux triple - "[[ARCH]]-unknown-linux-gnu"{{.*}"

// CHK-SYCL-FPGA-AUX-TRIPLE: clang{{.*}} "-cc1" "-triple" "[[ARCH]]-unknown-linux-gnu"{{.*}} "-aux-triple" "[[ARCH2]]-unknown-unknown"{{.*}} "-fsycl-is-host"

On Windows it is - "x86_64-pc-windows-msvc"

@pvchupin
Copy link
Contributor

Thanks @elizabethandrews, feel free to submit a PR with a fix.

@premanandrao
Copy link
Contributor Author

@premanandrao, please address post-commit issues on windows

PR #6355 fixes this.

@premanandrao
Copy link
Contributor Author

On Windows it is - "x86_64-pc-windows-msvc"

Indeed. Local testing did not catch this.

pvchupin pushed a commit that referenced this pull request Jun 24, 2022
PR #6295 modified Driver/sycl-offload.c incorrectly. It used a triple specific to Linux, and this failed on Windows.
This PR fixes that by checking a wildcard pattern for the other triple values.
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.

7 participants