-
Notifications
You must be signed in to change notification settings - Fork 801
[SYCL][clang] Fix more free-function kernel integration header cases #20877
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
base: sycl
Are you sure you want to change the base?
[SYCL][clang] Fix more free-function kernel integration header cases #20877
Conversation
This commit fixes a number of known issues when the integration header generates prototypes of the free-function kernels. These changes focus on the additional removal of aliasing and proper handling of templated template arguments. This commit also adds disabled test cases for a known issue with unresolved nested templated type aliases. These are cases for future work. Signed-off-by: Larsen, Steffen <[email protected]> Co-authored-by: Sachkov, Alexey <[email protected]>
Fznamznon
left a comment
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.
Just questions, will continue with meaningful review on Monday.
@elizabethandrews , @premanandrao given the size of the pr you're weclome to review as well.
clang/lib/Sema/SemaSYCL.cpp
Outdated
|
|
||
| const TemplateSpecializationType *TSTAsNonAlias = | ||
| TST->getAsNonAliasTemplateSpecializationType(); | ||
| TST->getAsTemplateSpecializationTypeWithoutAliases(Context); |
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.
So I was kind of expecting that the visitor soluiton would help us to avoid unwrapping and modifying types manually like getAsTemplateSpecializationTypeWithoutAliases does. Is that not the case? Could you please elaborate why do we need such a complex solution?
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 patch was the marriage between a patch @AlexeySachkov made and one that I prepared. The solution is still needed to avoid aliases, but it has now been integrated into the visitor, which I indeed think is the better solution. Good thinking!
Signed-off-by: Larsen, Steffen <[email protected]>
Signed-off-by: Larsen, Steffen <[email protected]>
This commit fixes the desugaring of independent aliased argument types in dependent free function kernels. Signed-off-by: Larsen, Steffen <[email protected]>
| ASTContext &Context) | ||
| : O(O), Policy(Policy), Context(Context) {} | ||
|
|
||
| void Visit(const TemplateSpecializationType *T, |
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.
Could you please give T and CT meaningful names or add a comment explaining what is what?
|
|
||
| const TemplateDecl *TD = CT->getTemplateName().getAsTemplateDecl(); | ||
| if (!TD->getIdentifier()) | ||
| TD = T->getTemplateName().getAsTemplateDecl(); |
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.
Is T guaranteed to have an identifier?
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 can't think of a case where it doesn't, but that doesn't mean it's impossible. I can introduce an unreachable or similar to error out instead of generating an invalid identifier if that is better?
|
|
||
| void VisitDeclarationTemplateArgument(const TemplateArgument &, | ||
| ArrayRef<TemplateArgument>) { | ||
| llvm_unreachable("Free function kernels cannot have non-type template " |
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.
Does it make sense to diagnose this case prior integration header emission? Like in SyclKernelFieldChecker.
|
|
||
| void VisitTemplateExpansionTemplateArgument(const TemplateArgument &Arg, | ||
| ArrayRef<TemplateArgument>) { | ||
| // Likely does not work similar to the one above |
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.
Is that a FIXME?
| // default argument. | ||
| // We pass specialized arguments in case there are references to them | ||
| // from other types. | ||
| // FIXME: passing SpecArgs here is incorrect. It refers to template |
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.
That FIXME does seem concerning.
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 agree, though the current version of this still addresses a chunk of the current issues we are seeing with the prototype generation. I can try to add some more disabled cases to the test so we know what to fix.
| } | ||
|
|
||
| void VisitExpressionTemplateArgument(const TemplateArgument &Arg, | ||
| ArrayRef<TemplateArgument>) { |
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.
It would be great to explain somewhere why all the methods additionally accept an ArrayRef that sometimes ends up unused.
| assert(E && "Failed to get an Expr for an Expression template arg?"); | ||
|
|
||
| if (Arg.isInstantiationDependent() || | ||
| E->getType().getTypePtr()->isScopedEnumeralType()) { |
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 we
| E->getType().getTypePtr()->isScopedEnumeralType()) { | |
| E->getType()->isScopedEnumeralType()) { |
This commit fixes a number of known issues when the integration header generates prototypes of the free-function kernels. These changes focus on the additional removal of aliasing and proper handling of templated template arguments.
This commit also adds disabled test cases for a known issue with unresolved nested templated type aliases. These are cases for future work.