Skip to content

[SYCL][NFC] Diagnostic message improvement for negative arguments values of work_group_size attributes #2988

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 3 commits into from
Jan 5, 2021

Conversation

smanna12
Copy link
Contributor

@smanna12 smanna12 commented Jan 4, 2021

Template parameter support for work_group_size attributes was added on
#2906

This is a follow-up comments in #2906 (comment)

This patch improves the diagnostic message for
"warn_attribute_requires_non_negative_integer_argument" and updates tests
related to this diagnostic.

Signed-off-by: Soumi Manna soumi.manna@intel.com

…s of work_group_size attributes

Template parameter support for work_group_size attributes was added on
intel#2906

This is a followup comments on intel#2906

This patch improves the diagnostic message for
"warn_attribute_requires_non_negative_integer_argument" and updates tests
related to this diagnostic.

Signed-off-by: Soumi Manna <soumi.manna@intel.com>
Signed-off-by: Soumi Manna <soumi.manna@intel.com>
@smanna12 smanna12 changed the title [SYCL][NFC] Diagnostic message improvment for negative aruments value… [SYCL][NFC] Diagnostic message improvement for negative arguments values of work_group_size attributes Jan 4, 2021
@smanna12 smanna12 marked this pull request as ready for review January 4, 2021 18:39
@smanna12 smanna12 requested a review from AaronBallman January 4, 2021 18:39
@@ -12981,7 +12981,8 @@ static bool handleMaxWorkSizeAttrExpr(Sema &S, const AttrInfo &AI,
if (ArgVal->isNegative()) {
S.Diag(Expr->getExprLoc(),
diag::warn_attribute_requires_non_negative_integer_argument)
<< &AI << Idx << Expr->getSourceRange();
<< S.Context.IntTy << S.Context.UnsignedIntTy
Copy link
Contributor

Choose a reason for hiding this comment

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

I think you should get the type out of the expression rather than hard-code IntTy -- the user could have done something like used an integer suffix that would give a different type, and the diagnostic would be somewhat confusing. e.g., 0LL instead of 0.

You should use UnsignedLongLongTy for the unsigned type as that's what we always wind up converting it to anyway.

Copy link
Contributor Author

@smanna12 smanna12 Jan 4, 2021

Choose a reason for hiding this comment

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

Thanks @AaronBallman for lookin into the patch.
If i understand correctly, do you mean to use something like << S.Context.IntTy << S.Context.UnsignedLongLongTy

I think you should get the type out of the expression rather than hard-code IntTy --

I will take a look at this and try to do this way.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nope, sorry for not being more clear. I mean something more like << Expr->getType() << S.Context.UnsignedLongLongTy

(as a drive-by, we may want to rename the variable Expr in this function to something that doesn't conflict with the type named Expr.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the explanation. Yes, it makes sense to me to use UnsignedLongLongTy for the unsigned type. I have renamed he variable Expr to avoid the conflicts with type names Expr.

Signed-off-by: Soumi Manna <soumi.manna@intel.com>
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.

Thanks, this LGTM!

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.

LGTM. Thanks!

@smanna12
Copy link
Contributor Author

smanna12 commented Jan 4, 2021

Thank you @elizabethandrews and @AaronBallman for the reviews.

@pvchupin pvchupin merged commit 84d2eb5 into intel:sycl Jan 5, 2021
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.

4 participants