Page MenuHomePhabricator

Anastasia (Anastasia Stulova)
Compiler Engineer at ARM / Code Owner of OpenCL in Clang

Projects

User does not belong to any projects.

User Details

User Since
Mar 5 2015, 8:05 AM (254 w, 1 d)

Recent Activity

Fri, Jan 3

Anastasia committed rGe456165f9fec: [OpenCL] Add link to C++ for OpenCL documentation (authored by Anastasia).
[OpenCL] Add link to C++ for OpenCL documentation
Fri, Jan 3, 4:14 AM
Anastasia closed D72076: [OpenCL] Add link to C++ for OpenCL documentation.
Fri, Jan 3, 4:14 AM · Restricted Project

Thu, Jan 2

Anastasia updated the diff for D72076: [OpenCL] Add link to C++ for OpenCL documentation.

Recovered lost bit of information.

Thu, Jan 2, 5:06 AM · Restricted Project
Anastasia created D72076: [OpenCL] Add link to C++ for OpenCL documentation.
Thu, Jan 2, 4:15 AM · Restricted Project

Fri, Dec 27

Anastasia committed rG752220ea2664: [OpenCL] Fixed printing of __private in AMDGPU test (authored by Anastasia).
[OpenCL] Fixed printing of __private in AMDGPU test
Fri, Dec 27, 9:10 AM
Anastasia added a comment to D71463: Implement VectorType conditional operator GNU extension..

It looks good, I was just thinking whether it would be possible to share more common infrastructure. There is Sema::CheckVectorOperands that corresponding OpenCL methods are using internally. Do you think it is possible to share the code more?

Fri, Dec 27, 9:00 AM · Restricted Project
Anastasia added inline comments to D71460: [OpenCL] Fix support for cl_khr_mipmap_image_writes.
Fri, Dec 27, 8:08 AM · Restricted Project
Anastasia accepted D71725: [OpenCL] Fix inconsistency between opencl and c11 atomic fetch max/min.

LGTM! Thanks!

Fri, Dec 27, 8:03 AM · Restricted Project
Anastasia committed rG869d17d851ba: [OpenCL] Pretty print __private addr space (authored by Anastasia).
[OpenCL] Pretty print __private addr space
Fri, Dec 27, 5:44 AM
Anastasia closed D71272: [OpenCL] Pretty print __private addr space.
Fri, Dec 27, 5:44 AM · Restricted Project

Dec 16 2019

Anastasia added inline comments to D71460: [OpenCL] Fix support for cl_khr_mipmap_image_writes.
Dec 16 2019, 11:58 AM · Restricted Project
Anastasia accepted D71476: [OpenCL] Add builtin function extension handling.

LGTM! Thanks!

Dec 16 2019, 11:49 AM · Restricted Project

Dec 13 2019

Anastasia added inline comments to D71272: [OpenCL] Pretty print __private addr space.
Dec 13 2019, 5:21 AM · Restricted Project
Anastasia committed rGed8dadb37c7e: [Sema] Improve diagnostic about addr spaces for overload candidates (authored by Anastasia).
[Sema] Improve diagnostic about addr spaces for overload candidates
Dec 13 2019, 4:36 AM
Anastasia closed D71111: [Sema] Improve diagnostic about addr spaces for overload candidates.
Dec 13 2019, 4:36 AM · Restricted Project

Dec 12 2019

Anastasia updated the diff for D71111: [Sema] Improve diagnostic about addr spaces for overload candidates.
  • Moved "address space" printing into diagnostic engine
  • Moved LangAS::Default into switch/case statement.
Dec 12 2019, 4:24 AM · Restricted Project
Anastasia accepted D71133: [OpenCL] Add ExtVectorElementExpr constant evaluation (PR42387).

LGTM! Thanks!

Dec 12 2019, 4:15 AM · Restricted Project
Anastasia added a reviewer for D71272: [OpenCL] Pretty print __private addr space: AlexeySotkin.
Dec 12 2019, 4:08 AM · Restricted Project

Dec 11 2019

Anastasia updated the diff for D71111: [Sema] Improve diagnostic about addr spaces for overload candidates.
  • Allow sending address spaces into diagnostics
  • Change wording of diagnostics for address spaces in overloading
Dec 11 2019, 11:29 AM · Restricted Project

Dec 10 2019

Anastasia added inline comments to D69878: Consoldiate internal denormal flushing controls.
Dec 10 2019, 9:03 AM · Restricted Project
Anastasia added inline comments to D71133: [OpenCL] Add ExtVectorElementExpr constant evaluation (PR42387).
Dec 10 2019, 8:53 AM · Restricted Project
Anastasia created D71272: [OpenCL] Pretty print __private addr space.
Dec 10 2019, 7:33 AM · Restricted Project

Dec 6 2019

Anastasia created D71111: [Sema] Improve diagnostic about addr spaces for overload candidates.
Dec 6 2019, 4:57 AM · Restricted Project

Dec 5 2019

Anastasia accepted D71015: [OpenCL] Handle address space conversions for constexpr (PR44177).

LGTM! Thanks!

Dec 5 2019, 4:21 AM · Restricted Project
Anastasia accepted D71005: [AST] Enable expression of OpenCL language address spaces an attribute.

I presume OpenCL addr space logic won't apply in all cases in non-OpenCL compilations i.e. for example C++ because we enclose some of the logic under LangOpts checks.

Dec 5 2019, 3:07 AM · Restricted Project

Dec 4 2019

Anastasia accepted D70981: [opencl] Fix address space deduction on array variables..

LGTM! Thanks! Please address the comment in your final commit.

Dec 4 2019, 5:38 AM · Restricted Project
Anastasia added inline comments to D71005: [AST] Enable expression of OpenCL language address spaces an attribute.
Dec 4 2019, 5:11 AM · Restricted Project
Anastasia committed rGe6522a96f56c: [OpenCL] Allow addr space qualifiers on lambda call expressions (authored by Anastasia).
[OpenCL] Allow addr space qualifiers on lambda call expressions
Dec 4 2019, 4:34 AM
Anastasia closed D70242: [OpenCL] Allow addr space qualifiers on lambda call expressions.
Dec 4 2019, 4:34 AM · Restricted Project

Dec 3 2019

Anastasia committed rG980133a2098c: [OpenCL] Use generic addr space for lambda call operator (authored by Anastasia).
[OpenCL] Use generic addr space for lambda call operator
Dec 3 2019, 8:14 AM
Anastasia closed D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .
Dec 3 2019, 8:14 AM · Restricted Project

Nov 28 2019

Anastasia updated the diff for D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .

Switched to using getAddrSpaceQualType in the entire code base.

Nov 28 2019, 4:53 AM · Restricted Project
Anastasia resigned from D60455: [SYCL] Add sycl_kernel attribute for accelerated code outlining.

Sorry, I don't have capacity currently to review this and I don't want to be blocking it either.

Nov 28 2019, 3:28 AM · Restricted Project

Nov 27 2019

Anastasia updated the diff for D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .

Added getDefaultCXXMethodAddrSpace helper to Sema

Nov 27 2019, 6:54 AM · Restricted Project
Anastasia committed rGa29aa4710620: [OpenCL] Move addr space deduction to Sema. (authored by Anastasia).
[OpenCL] Move addr space deduction to Sema.
Nov 27 2019, 4:47 AM
Anastasia closed D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
Nov 27 2019, 4:47 AM · Restricted Project

Nov 26 2019

Anastasia added inline comments to D69878: Consoldiate internal denormal flushing controls.
Nov 26 2019, 9:15 AM · Restricted Project
Anastasia added inline comments to D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .
Nov 26 2019, 2:44 AM · Restricted Project

Nov 25 2019

Anastasia added a comment to D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .

Yes, in that case copy-elision into the global variable is guaranteed. You can write arbitrary expressions in global initializers, however, and those can use temporary lambdas.

I guess you mean something like this?

auto glambda = []() { return 1; }();

Yes, or just passing it as an argument to something.

I don't see a way to change the address space of a lambda object however. It would only be possible to specify addr space qualifiers for a call operator of such lambdas.

Yes, I think the language has to say what address space the lambda temporary is in. Among other things, this can affect how captures are initialized, since some constructors are only usable in certain address spaces. (Lambdas in global contexts can't capture surrounding local variables, but they can still have explicitly-initialized captures, like [x=foo()] { ... }.) That language rule could be that lambda temporaries are always in the private address space, or it could be that lambdas in global contexts are in the global address space. The latter might be easier because it's compatible with lifetime-extension: we don't necessarily know when processing the lambda whether its temporary will be lifetime-extended, and if it is, it needs to be in the global address space. The only disadvantage of that is that we'd have to use global memory even for non-extended temporaries in global initializers.

Richard might have thoughts about this. I don't know if there's been any language work around copy-elision and/or lifetime-extension that might be stretchable to allow us to delay the address-space decision until later.

Nov 25 2019, 11:14 AM · Restricted Project

Nov 22 2019

Anastasia added a comment to D68388: [PR41008][OpenCL] Add OpenCL C compatibility mode to C++ for OpenCL.

Thanks for the feedback.

I think we should use -fpermissive rather than adding similar flag to Clang.

Could you point me at a use of -fpermissive for a similar case? Also it seems -fpermissive is not mentioned in the Clang manual or the help text. Am I missing something?

Nov 22 2019, 6:05 AM · Restricted Project
Anastasia added a comment to D68388: [PR41008][OpenCL] Add OpenCL C compatibility mode to C++ for OpenCL.

I think we should use -fpermissive rather than adding similar flag to Clang. At the end we might end up with other cases where we need similar mechanism it doesn't make sense to add a flag for each case.

Nov 22 2019, 5:01 AM · Restricted Project

Nov 21 2019

Anastasia added a comment to D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .

Yes, in that case copy-elision into the global variable is guaranteed. You can write arbitrary expressions in global initializers, however, and those can use temporary lambdas.

Nov 21 2019, 4:32 AM · Restricted Project

Nov 19 2019

Anastasia added inline comments to D69878: Consoldiate internal denormal flushing controls.
Nov 19 2019, 8:24 AM · Restricted Project
Anastasia updated the diff for D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .
  • Added FIXME to enhance testing.
Nov 19 2019, 7:26 AM · Restricted Project
Anastasia added a comment to D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .

I was already planning to add this. I could look into it next and maybe just a add FIXME in the test for now.

Sure.

Btw global lambda objects are in __global address space in OpenCL.

Just based on being written outside of a function body or in a static-local initializer? I guess it's supportable; you can reasonably allocate global memory for those temporaries.

Nov 19 2019, 7:06 AM · Restricted Project
Anastasia added a comment to D70242: [OpenCL] Allow addr space qualifiers on lambda call expressions.

Well that was easy.

Do we accept the address-space attribute in this position, or is that TBD?

Nov 19 2019, 4:28 AM · Restricted Project

Nov 15 2019

Anastasia added a comment to D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .

It does make logical sense to be able to qualify the call operator of a lambda. The lambda always starts as a temporary, so presumably we want the default address space qualifier on lambdas to be compatible with the address space of temporaries. However, that's probably also true of the default address qualifier on methods in general or you wouldn't be able to call them on temporaries and locals. Thus, we should be able to use the same default in both cases, which seems to be what you've implemented.

It even makes sense to be able to qualify a lambda with an address space that's not compatible with the address space of temporaries; that just means that the lambda has to be copied elsewhere before it can be invoked.

Just to clarify... Do you mean we should be able to compile this example:

[&] __global {
      i++;
} ();

Or should this result in a diagnostic about an addr space mismatch?

It should result in a diagnostic on the call. But if you assigned that lambda into global memory (somehow) it should work.

Ok, makes sense so something like this should compile fine:

__global auto glob = [&] __global { ... };

Right, a call to glob() should work in this case. I don't know if __global would parse here without (), though; in the grammar, it looks like attributes and so on have to follow an explicit parameter clause.

  1. Diagnose address space mismatch between variable decl and lambda expr qualifier Example: private auto llambda = [&]() local {i++;}; // error no legal conversion b/w private and local

    I think 1 is covered by this patch. I would like to implement 2 as a separate patch though to be able to commit fix for 1 earlier and unblock some developers waiting for the fix. I think 3 already works and I will just update the diagnostic in a separate patch too.

I agree that 3 should just fall out. And yeah, implementing 2 as a separate patch should be fine. Please make sure 3 is adequately tested in this patch.

Ok, since we can't qualify lambda expr with addr spaces yet there is not much I can test at this point. __constant lambda variable seems to be the only case with a diagnostic for OpenCL.

You can certainly copy a lambda type into a different address space, or construct a pointer to a qualified lambda type, e.g. (*(__constant decltype(somelambda) *) nullptr)().

Perhaps I am not thinking of the right use cases, but I am struggling to understand what would be the difference to variables of other type here.

I have added (*(__constant decltype(somelambda) *) nullptr)() as a test case however. It is rejected due to multiple addr spaces.

Hmm. That makes sense — decltype is picking up the address-space qualification of somelambda — but seems unfortunate; is the only way to change the address space of a type to specifically strip the address space with a template metaprogram?

Nov 15 2019, 3:03 AM · Restricted Project

Nov 14 2019

Anastasia updated the diff for D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .
  • Added pointer to lambda test case.
Nov 14 2019, 7:21 AM · Restricted Project
Anastasia added a comment to D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .

It does make logical sense to be able to qualify the call operator of a lambda. The lambda always starts as a temporary, so presumably we want the default address space qualifier on lambdas to be compatible with the address space of temporaries. However, that's probably also true of the default address qualifier on methods in general or you wouldn't be able to call them on temporaries and locals. Thus, we should be able to use the same default in both cases, which seems to be what you've implemented.

It even makes sense to be able to qualify a lambda with an address space that's not compatible with the address space of temporaries; that just means that the lambda has to be copied elsewhere before it can be invoked.

Just to clarify... Do you mean we should be able to compile this example:

[&] __global {
      i++;
} ();

Or should this result in a diagnostic about an addr space mismatch?

It should result in a diagnostic on the call. But if you assigned that lambda into global memory (somehow) it should work.

Ok, makes sense so something like this should compile fine:

__global auto glob = [&] __global { ... };

Right, a call to glob() should work in this case. I don't know if __global would parse here without (), though; in the grammar, it looks like attributes and so on have to follow an explicit parameter clause.

  1. Diagnose address space mismatch between variable decl and lambda expr qualifier Example: private auto llambda = [&]() local {i++;}; // error no legal conversion b/w private and local

    I think 1 is covered by this patch. I would like to implement 2 as a separate patch though to be able to commit fix for 1 earlier and unblock some developers waiting for the fix. I think 3 already works and I will just update the diagnostic in a separate patch too.

I agree that 3 should just fall out. And yeah, implementing 2 as a separate patch should be fine. Please make sure 3 is adequately tested in this patch.

Ok, since we can't qualify lambda expr with addr spaces yet there is not much I can test at this point. __constant lambda variable seems to be the only case with a diagnostic for OpenCL.

You can certainly copy a lambda type into a different address space, or construct a pointer to a qualified lambda type, e.g. (*(__constant decltype(somelambda) *) nullptr)().

Nov 14 2019, 7:21 AM · Restricted Project
Anastasia created D70242: [OpenCL] Allow addr space qualifiers on lambda call expressions.
Nov 14 2019, 7:12 AM · Restricted Project
Anastasia updated the summary of D70242: [OpenCL] Allow addr space qualifiers on lambda call expressions.
Nov 14 2019, 7:12 AM · Restricted Project

Nov 12 2019

Anastasia added a comment to D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .

It does make logical sense to be able to qualify the call operator of a lambda. The lambda always starts as a temporary, so presumably we want the default address space qualifier on lambdas to be compatible with the address space of temporaries. However, that's probably also true of the default address qualifier on methods in general or you wouldn't be able to call them on temporaries and locals. Thus, we should be able to use the same default in both cases, which seems to be what you've implemented.

It even makes sense to be able to qualify a lambda with an address space that's not compatible with the address space of temporaries; that just means that the lambda has to be copied elsewhere before it can be invoked.

Just to clarify... Do you mean we should be able to compile this example:

[&] __global {
      i++;
} ();

Or should this result in a diagnostic about an addr space mismatch?

It should result in a diagnostic on the call. But if you assigned that lambda into global memory (somehow) it should work.

Nov 12 2019, 4:04 AM · Restricted Project
Anastasia updated the diff for D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .
  • Added missing handling of lambda w/o param list.
Nov 12 2019, 4:04 AM · Restricted Project

Nov 11 2019

Anastasia added a comment to D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .

It does make logical sense to be able to qualify the call operator of a lambda. The lambda always starts as a temporary, so presumably we want the default address space qualifier on lambdas to be compatible with the address space of temporaries. However, that's probably also true of the default address qualifier on methods in general or you wouldn't be able to call them on temporaries and locals. Thus, we should be able to use the same default in both cases, which seems to be what you've implemented.

It even makes sense to be able to qualify a lambda with an address space that's not compatible with the address space of temporaries; that just means that the lambda has to be copied elsewhere before it can be invoked.

Nov 11 2019, 10:40 AM · Restricted Project

Nov 7 2019

Anastasia added inline comments to D69810: [OpenCL] Fix address space for base method call (PR43145).
Nov 7 2019, 4:39 AM · Restricted Project
Anastasia added a comment to D69878: Consoldiate internal denormal flushing controls.

Stop emitting the denorms-are-zero attribute for the OpenCL flag. It
has no in-tree users. The meaning would also be target dependent, such
as the AMDGPU choice to treat this as only meaning allow flushing of
f32 and not f16 or f64. The naming is also potentially confusing,
since DAZ in other contexts refers to instructions implicitly treating
input denormals as zero, not necessarily flushing output denormals to
zero.

Nov 7 2019, 4:37 AM · Restricted Project
Anastasia accepted D69908: [OpenCL] Add geometric and relational builtin functions.

LGTM! Thanks!

Nov 7 2019, 4:10 AM · Restricted Project
Anastasia accepted D69901: [OpenCL] Add integer functions to builtin functions.

LGTM! Thanks!

Nov 7 2019, 4:02 AM · Restricted Project
Anastasia accepted D69883: [OpenCL] Add math and common builtin functions.

I guess we need to think about testing quite soon. :)

Nov 7 2019, 4:01 AM · Restricted Project
Anastasia added a reviewer for D69810: [OpenCL] Fix address space for base method call (PR43145): rjmccall.
Nov 7 2019, 3:53 AM · Restricted Project
Anastasia created D69938: [OpenCL] Use __generic addr space when generating internal representation of lambda .
Nov 7 2019, 3:42 AM · Restricted Project

Nov 5 2019

Anastasia added inline comments to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
Nov 5 2019, 3:28 AM · Restricted Project
Anastasia updated the diff for D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
  • Factored OpenCL diagnostics out in a separate helper function
  • Removed special case for ParenType
Nov 5 2019, 3:28 AM · Restricted Project

Nov 4 2019

Anastasia accepted D63557: [OpenCL] Group builtin functions by prototype.

LGTM! Feel free to change comments on the final commit! Thanks!

Nov 4 2019, 4:20 AM · Restricted Project, Restricted Project
Anastasia accepted D68781: [OpenCL] Fix address space for const method call from nonconst.

LGTM! Thanks

Nov 4 2019, 3:08 AM · Restricted Project

Nov 1 2019

Anastasia added inline comments to D63557: [OpenCL] Group builtin functions by prototype.
Nov 1 2019, 8:44 AM · Restricted Project, Restricted Project
Anastasia added a comment to D69498: IR: Invert convergent attribute handling.

It absolutely makes sense for Clang as a GPU-programming frontend to set attributes appropriately when targeting the GPU. I'm objecting to making "convergence" and related "code layout is semantics" properties a universal part of the IR semantics that literally every frontend has to know about in order to get reasonable behavior from LLVM. I know that doing so makes sense to GPU backend developers because you mostly work exclusively on GPU toolchains, but AFAIK there are half a dozen GPU frontends and they're all forks of Clang, whereas there are dozens of LLVM frontends out there that don't care about targeting the GPU and quite possibly never will. (And even if they do target GPUs, they often will not care about exposing thread groups; many programming environments are just interested in taking advantage of the GPU's parallel-computation power and have no interest in inter-thread interference.)

John.

I agree that the issue with making it "transparent" as a concept to whoever is not interested in programming models that have the concept of SIMD-wide execution is an open issue (not only related to this patch, but in general to the convergent idea as a whole, where writing a llvm pass that maintains convergence now is an extra burden to the developer of such pass that wasn't there before and that is probably completely orthogonal to the interest of the pass writer probably targeting C/C++ or other non-parallel languages). I opened some discussions going on the other related RFC for extending the concept of convergent to avoid hoisting as well regarding how are we gonna avoid burdening the LLVM community and maintain the invariants we want with respect to this concept.
I have no idea what the impact of the convergent attribute is in Clang (with the exception of adding the flag itself), but a lot of the heavy-lifting I know its in LVLM itself.

That said I just want to point out that some of these languages run on CPUs as well (like openCL ) and they share the same properties with respect to instructions that read execution masks of neighboring threads and making sure threads stay converged when executing them. It's certainly unfortunate that LLVM has some deficiencies in supporting these concepts and that the so far proposed solutions are not burden free for the rest of the community. :-/

Nov 1 2019, 6:07 AM · Restricted Project
Anastasia accepted D69242: [Sema] Make helper in TreeTransform.h 'inline' instead of 'static'. NFC.

I agree. LGTM! Thanks!

Nov 1 2019, 4:15 AM · Restricted Project
Anastasia accepted D69233: [OpenCL] Support -fdeclare-opencl-builtins in C++ mode.

LGTM! Thanks!

Nov 1 2019, 4:09 AM · Restricted Project

Oct 17 2019

Anastasia accepted D68403: [OpenCL] PR43145: preserve addrspace for class accesses.

LGTM! Thanks!

Oct 17 2019, 4:48 AM · Restricted Project
Anastasia updated the diff for D69072: [OpenCL] Added doc to describe OpenCL support.

Added OpenCLSupport page into index.

Oct 17 2019, 3:51 AM · Restricted Project
Anastasia added a comment to D69072: [OpenCL] Added doc to describe OpenCL support.

Shouldn't this page be referenced from clang/docs/index.rst?

Oct 17 2019, 3:13 AM · Restricted Project

Oct 16 2019

Anastasia created D69072: [OpenCL] Added doc to describe OpenCL support.
Oct 16 2019, 3:36 PM · Restricted Project

Oct 10 2019

Anastasia created D68781: [OpenCL] Fix address space for const method call from nonconst.
Oct 10 2019, 4:24 AM · Restricted Project

Oct 4 2019

Anastasia added a comment to D68388: [PR41008][OpenCL] Add OpenCL C compatibility mode to C++ for OpenCL.

Can you please explain why we are deviating from C++ on this? My concern is that this can potentially uncover bugs in C++ parsing due to un-handled restrict cases that would have to be fixed in some unclear way... I would appreciate more detailed analysis before we go ahead.

Oct 4 2019, 3:10 AM · Restricted Project

Sep 27 2019

Anastasia accepted D64319: [OpenCL] Add function attributes handling for builtin functions.

LGTM! Thanks!

Sep 27 2019, 11:37 AM · Restricted Project, Restricted Project

Sep 25 2019

Anastasia added inline comments to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
Sep 25 2019, 5:55 PM · Restricted Project

Sep 24 2019

Anastasia accepted D67714: [OpenCL] Add -Wconversion to fdeclare-opencl-builtins test.

LGTM!

Sep 24 2019, 2:47 PM · Restricted Project, Restricted Project
Anastasia added inline comments to D67714: [OpenCL] Add -Wconversion to fdeclare-opencl-builtins test.
Sep 24 2019, 8:21 AM · Restricted Project, Restricted Project
Anastasia accepted D67713: [OpenCL] Add image query builtin functions.

LGTM! Thanks!

Sep 24 2019, 8:16 AM · Restricted Project, Restricted Project

Sep 13 2019

Anastasia accepted D63504: [OpenCL] Add version handling and add vector ld/st builtins.

LGTM! Thanks!

Sep 13 2019, 3:59 AM · Restricted Project, Restricted Project

Sep 12 2019

Anastasia added inline comments to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
Sep 12 2019, 6:45 AM · Restricted Project
Anastasia updated the diff for D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
  • Move addr space deduction to a later phase.
Sep 12 2019, 6:32 AM · Restricted Project

Sep 4 2019

Anastasia updated the diff for D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
  • Added forgotten test
Sep 4 2019, 5:47 AM · Restricted Project
Anastasia added a comment to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.

I think this looks good. Maybe the tests should be extended to test auto as function return type, and if there's some special handling around decltype(auto), then it should be tested too, but I'm not sure it's actually needed here. What do you think?

Sep 4 2019, 4:06 AM · Restricted Project
Anastasia added inline comments to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.
Sep 4 2019, 4:05 AM · Restricted Project
Anastasia added a comment to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.

I don't think this is likely to change. Are you suggesting to move the deduction logic for pointee of pointers, references and block pointers into ASTContext helper that creates a pointer/reference/block pointer type?

No. I'm suggesting that the deduction logic should be much more straightforward, just some sort of "is the type non-dependent and lacking a qualifier", and it should be applied in the two basic places we build these types in Sema, i.e. in the type-from-declarator logic and in the Build{Pointer,Reference}Type logic.

Sep 4 2019, 4:03 AM · Restricted Project
Anastasia updated the diff for D65744: [PR42707][OpenCL] Fix addr space deduction for auto.

Moved addr space of pointee inference into Build* helpers of Sema.

Sep 4 2019, 4:01 AM · Restricted Project

Sep 3 2019

Anastasia accepted D63480: [OpenCL] Add image type handling for builtin functions.

LGTM! Thanks!

Sep 3 2019, 8:41 AM · Restricted Project, Restricted Project

Aug 30 2019

Anastasia added a comment to D65744: [PR42707][OpenCL] Fix addr space deduction for auto.

missing test case

Aug 30 2019, 3:26 AM · Restricted Project

Aug 28 2019

Anastasia added inline comments to D63480: [OpenCL] Add image type handling for builtin functions.
Aug 28 2019, 11:13 AM · Restricted Project, Restricted Project
Anastasia accepted D66883: PR42045: Fix diagnosing enqueue_kernel call with too few args.

LGTM! Thanks!

Aug 28 2019, 7:44 AM · Restricted Project, Restricted Project

Aug 23 2019

Anastasia committed rGad5047d23dda: [OpenCL] Renamed value of std flag in C++ mode. (authored by Anastasia).
[OpenCL] Renamed value of std flag in C++ mode.
Aug 23 2019, 10:11 AM
Anastasia committed rGd0b88fce0a21: [Docs][OpenCL] Release 9.0 notes for OpenCL (authored by Anastasia).
[Docs][OpenCL] Release 9.0 notes for OpenCL
Aug 23 2019, 6:56 AM
Anastasia committed rG976022e35c74: [Docs][OpenCL] Several corrections to C++ for OpenCL (authored by Anastasia).
[Docs][OpenCL] Several corrections to C++ for OpenCL
Aug 23 2019, 4:45 AM

Aug 19 2019

Anastasia updated the diff for D64418: [Docs][OpenCL] Documentation of C++ for OpenCL mode.

Added small corrections in various parts.

Aug 19 2019, 9:17 AM · Restricted Project
Anastasia accepted D63442: [OpenCL] Add const, volatile and pointer handling for builtin functions.

LGTM! Thanks!

Aug 19 2019, 7:54 AM · Restricted Project, Restricted Project
Anastasia updated the diff for D66294: [Docs][OpenCL] Release 9.0 notes for OpenCL.
  • Added empty line and ; as requested on the review.
Aug 19 2019, 7:34 AM · Restricted Project
Anastasia committed rGeb801abd5817: [OpenCL] Fix addr space deduction for pointers/references to arrays. (authored by Anastasia).
[OpenCL] Fix addr space deduction for pointers/references to arrays.
Aug 19 2019, 4:45 AM
Anastasia accepted D65456: [OpenCL] Add generic type handling for builtin functions.

LGTM! Thanks!

Aug 19 2019, 3:48 AM · Restricted Project, Restricted Project