Skip to content

Conversation

@steffenlarsen
Copy link
Contributor

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.

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]>
Copy link
Contributor

@Fznamznon Fznamznon left a 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.


const TemplateSpecializationType *TSTAsNonAlias =
TST->getAsNonAliasTemplateSpecializationType();
TST->getAsTemplateSpecializationTypeWithoutAliases(Context);
Copy link
Contributor

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?

Copy link
Contributor Author

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!

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,
Copy link
Contributor

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

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?

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 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 "
Copy link
Contributor

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

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

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.

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

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

Choose a reason for hiding this comment

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

can we

Suggested change
E->getType().getTypePtr()->isScopedEnumeralType()) {
E->getType()->isScopedEnumeralType()) {

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.

2 participants