This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Add constant address space to __func__ in AST
ClosedPublic

Authored by Anastasia on Apr 25 2018, 3:11 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

Anastasia created this revision.Apr 25 2018, 3:11 AM
svenvh added a subscriber: svenvh.Apr 25 2018, 3:12 AM
svenvh added inline comments.Apr 25 2018, 3:31 AM
lib/Sema/SemaExpr.cpp
3056 ↗(On Diff #143886)

Nitpick: local indent style is 2 spaces.

test/SemaOpenCL/predefind-expr.cl
1 ↗(On Diff #143886)

predefind-expr.cl -> predefined_expr.cl

Also please indent the function body.

bader added inline comments.Apr 25 2018, 7:05 AM
lib/Sema/SemaExpr.cpp
3059 ↗(On Diff #143886)

Will it work if we fix this issue inside StringLiteral::Create method?
I just hope it will help us avoid code duplication.

  • Renamed test;
  • Reformatted;
  • Added constant in StringLiteral creation.
bader accepted this revision.Apr 26 2018, 10:38 AM
bader added inline comments.
lib/Sema/SemaExpr.cpp
3056 ↗(On Diff #144154)

Do we still need this?

This revision is now accepted and ready to land.Apr 26 2018, 10:38 AM
Anastasia added inline comments.Apr 26 2018, 11:09 AM
lib/Sema/SemaExpr.cpp
3059 ↗(On Diff #143886)

I have added the address space to the creation of StringLiteral, but unfortunately it doesn't seems like we can remove similar code in other places because QualType created for StringLiteral is also used elsewhere and has to match (contain right address space). I.e. here is it used further down to create PredefinedExpr.

So not sure there is any value in doing the change in StringLiteral construction really. Unless we could keep it and use getType() from StringLiteral to resent the QualType to be used further down. Let me know what you think about it?

bader added inline comments.Apr 26 2018, 1:43 PM
lib/AST/Expr.cpp
870 ↗(On Diff #144154)

As Ty is passed by value, shouldn't we accept only data located in constant address space?

lib/Sema/SemaExpr.cpp
3057 ↗(On Diff #144154)

String type can only be a constant arrays.
Can we set constant address space inside this getter for OpenCL language?
Or we might want constant array in other address spaces e.g. private?

Anastasia added inline comments.Apr 27 2018, 3:05 AM
lib/AST/Expr.cpp
870 ↗(On Diff #144154)

Do you mean to assert? Currently it should be passed with constant AS but I thought the idea is to modify this function so we can accept Default AS too but then replace by constant.

lib/Sema/SemaExpr.cpp
3057 ↗(On Diff #144154)

Yes, I think we need to be able to declare const arrays in different ASes. I.e. this is valid code in OpenCL:

__private const int* a = ...;

Quick check for getConstantArrayType, it seems to be used in many different place. So I don't think I can just modify it.

bader added inline comments.Apr 27 2018, 6:14 AM
lib/AST/Expr.cpp
870 ↗(On Diff #144154)

Yes, but according to your other comment this idea doesn't work.

I have added the address space to the creation of StringLiteral, but unfortunately it doesn't seems like we can remove similar code in other places because QualType created for StringLiteral is also used elsewhere and has to match (contain right address space). I.e. here is it used further down to create PredefinedExpr.

Anastasia added inline comments.Apr 27 2018, 7:24 AM
lib/AST/Expr.cpp
870 ↗(On Diff #144154)

Indeed for the current cases it doesn't... there might be some uncaught ones though where it can be useful. But we can add it later as well. So I am thinking to undo this?

Anastasia added inline comments.Apr 27 2018, 7:33 AM
lib/AST/Expr.cpp
870 ↗(On Diff #144154)

I quite liked the idea initially, but unfortunately it seems like it's not applicable to the current use cases.

Can you add a codegen test for 1.2, 2.0?

Also, I am wondering whether this is valid for OpenCL C++. Do we need special handling for string literal?

lib/AST/Expr.cpp
870 ↗(On Diff #144154)

Can you extract this as

QualType ASTContext::getStringLiteralType(QualType);

then use it here and below?

test/SemaOpenCL/predefined-expr.cl
1 ↗(On Diff #144154)

can you also check for cl 2.0?

Anastasia updated this revision to Diff 144885.May 2 2018, 8:04 AM

The best way of adding common helper function I could come up with. The problem is that string literals are created quite differently all over: using various char types and const qualifiers. That seems to cover the most common case now.

Anastasia updated this revision to Diff 144892.May 2 2018, 8:43 AM

Added accidentally removed code and improved the test.

Can you add a codegen test for 1.2, 2.0?

Anything specific you would like me to check? I am not modifying anything in CodeGen here though.

Also, I am wondering whether this is valid for OpenCL C++. Do we need special handling for string literal?

Actually OpenCL C++ makes no statement about string literal. But I think we will want it to be in constant AS. I will raise it with Khronos.

Can you add a codegen test for 1.2, 2.0?

Anything specific you would like me to check? I am not modifying anything in CodeGen here though.

You changed the AST of string literal. We need to check whether the CodeGen for string literal still works.

lib/AST/ASTContext.cpp
3632 ↗(On Diff #144892)

This is not right. The base type of a string literal may not be CharTy, therefore this function needs an input argument which is the original base type and it returns the adjusted base type. (Maybe it should be renamed as adjustStringLiteralBaseType?) Also, you can then use it in StringLiteral::CreateEmpty by passing an empty QualType().

Anastasia updated this revision to Diff 145000.May 3 2018, 4:18 AM
  • Changed to adjust common function
  • Enhanced CodeGen string literal case to also check the predefined expr
yaxunl accepted this revision.May 3 2018, 12:40 PM

LGTM. Thanks!

This revision was automatically updated to reflect the committed changes.