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 (265 w, 5 d)

Recent Activity

Thu, Mar 26

Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Thu, Mar 26, 6:28 AM · Restricted Project
Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Thu, Mar 26, 6:28 AM · Restricted Project
Anastasia added a comment to D76636: [RFC] Added type trait to remove address space qualifier from type.

Address spaces are actually defined in a number of standardized C extensions that are compatible with C++, such as the Embedded C specification, OpenCL, and so on. There's precedent for libc++ accepting work that supports this kind of C++-compatible extension in the past; for example, std::is_pointer looks through Objective-C's ARC type qualifiers. That said, (1) libc++ hasn't actually added new traits for such things before, just taught existing traits to handle them, and (2) I think this definition wouldn't actually work for cases like the OpenCL address spaces because they're not expressible as __attribute__((address_space(N))). (2) is fixable; (1) may be a reasonable place to draw the line on policy.

Regarding (2) (although it's probably not changing the major concerns) this exact implementation also works for OpenCL because we map the address space keywords to the attributes during the parsing. However, OpenCL currently doesn't support libcxx. :(

Ah, okay. Maybe it's one of the other languages that keeps its address spaces separate from address_space.

Regardless, if libc++ wants to have a policy of not adding new features that cover non-C++ features, that's a reasonable stance.

Thu, Mar 26, 5:55 AM

Wed, Mar 25

Anastasia added a comment to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..

Sorry for the delayed comments. It would be good to address those in a separate commit if possible.

Wed, Mar 25, 10:16 AM · Restricted Project
Anastasia added a comment to D76636: [RFC] Added type trait to remove address space qualifier from type.

I agree with @EricWF here. Libc++ shouldn't become a repository of useful but non-standard utilities. It's useful to sometimes extend standard tools to non-standard concepts (like handling some Objective-C qualifiers when we can), but adding something new that hasn't been standardized is not really the business we want to be into.

However, @Anastasia , you could consider proposing the attribute for standardization, and if that makes the cut, then we'll be happy to implement it.

Cheers!

Wed, Mar 25, 10:15 AM
Anastasia added a comment to D76636: [RFC] Added type trait to remove address space qualifier from type.

Address spaces are actually defined in a number of standardized C extensions that are compatible with C++, such as the Embedded C specification, OpenCL, and so on. There's precedent for libc++ accepting work that supports this kind of C++-compatible extension in the past; for example, std::is_pointer looks through Objective-C's ARC type qualifiers. That said, (1) libc++ hasn't actually added new traits for such things before, just taught existing traits to handle them, and (2) I think this definition wouldn't actually work for cases like the OpenCL address spaces because they're not expressible as __attribute__((address_space(N))). (2) is fixable; (1) may be a reasonable place to draw the line on policy.

Wed, Mar 25, 9:43 AM

Mon, Mar 23

Anastasia created D76636: [RFC] Added type trait to remove address space qualifier from type.
Mon, Mar 23, 12:00 PM

Thu, Mar 12

Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Thu, Mar 12, 7:03 AM · Restricted Project

Tue, Mar 10

Anastasia added inline comments to D75917: Expose llvm fence instruction as clang intrinsic.
Tue, Mar 10, 9:46 AM · Restricted Project
Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Tue, Mar 10, 5:12 AM · Restricted Project

Mar 4 2020

Anastasia added a comment to D75285: Mark restrict pointer or reference to const as invariant.

That is not true for two reasons: first, restrict guarantees that the variable is not accessed through any non-derived l-value within its scope, and that would certainly include from other threads; and second, it is undefined behavior for two threads to access the same object without synchronizing anyway (unless they're both just reading from it).

How about the cases where users cannot use restrict but they still want to mark a pointer as invariant? Or even though restrict is used but it is too complicated for alias analysis to deduce invariance?

Mar 4 2020, 10:38 AM

Mar 3 2020

Anastasia added a comment to D75285: Mark restrict pointer or reference to const as invariant.

Are you sure restrict alone isn't good enough? It doesn't directly tell you that the memory is invariant, but it's usually simple to prove that the memory isn't modified within the restrict scope, which might be sufficient.

Mar 3 2020, 4:35 AM

Feb 27 2020

Anastasia added a comment to D74910: [OpenCL] Remove spurious atomic_fetch_min/max builtins.

I would say if we are not aware of any test that this change breaks, let's go ahead and commit this?

Feb 27 2020, 4:53 AM · Restricted Project
Anastasia added a comment to D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.

Thanks for writing notes! Go ahead and push directly to the branch when you're ready.

Feb 27 2020, 3:46 AM
Anastasia added a comment to D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.

@hans, what is the current process for committing to the release branch? Would you be able to commit this or would you prefer that I commit myself?

Feb 27 2020, 3:42 AM

Feb 26 2020

Anastasia updated the diff for D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.

Addressed comments from Hans and Sven.

Feb 26 2020, 9:50 AM

Feb 25 2020

Anastasia added inline comments to D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.
Feb 25 2020, 8:37 AM
Anastasia added a reviewer for D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL: hans.
Feb 25 2020, 8:37 AM
Anastasia created D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.
Feb 25 2020, 8:35 AM
Anastasia committed rGfa755d3e71ed: [Sema][C++] Propagate conversion kind to specialize the diagnostics (authored by Anastasia).
[Sema][C++] Propagate conversion kind to specialize the diagnostics
Feb 25 2020, 8:09 AM
Anastasia closed D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 25 2020, 8:08 AM · Restricted Project

Feb 20 2020

Anastasia updated the diff for D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
  • Always set isInvalid for all error cases.
  • Hoist setting isInvalid together with an error diagnostic.
  • Updated more tests.
Feb 20 2020, 6:59 AM · Restricted Project

Feb 19 2020

Anastasia added inline comments to D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 19 2020, 12:14 PM · Restricted Project

Feb 18 2020

Anastasia updated the diff for D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
  • Updated expected diagnostics for function pointer tests
  • Make DiagnoseAsignmentResult return true for all incompatible cases in C++
Feb 18 2020, 7:48 AM · Restricted Project

Feb 17 2020

Anastasia added inline comments to D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 17 2020, 3:14 AM · Restricted Project

Feb 14 2020

Anastasia added a comment to D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.

It looks like there's already some type analysis in DiagnoseAssignmentResult to get a specialized diagnostic for certain cases of function-pointer assignment. That could probably be easily moved into CheckAssignmentConstraints by just adding a few more cases to AssignConvertResult.

One interesting effect I get after modifying this that some extra tests in C mode started to report function pointer instead of generic pointer warning. I feel this is because in checkPointerTypesForAssignment we use canonical types and in DiagnoseAssignmentResult we don't.

Feb 14 2020, 9:45 AM · Restricted Project
Anastasia updated the diff for D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
  • Switched to using CheckAssignmentConstraints
  • Duplicated all extensions and warnings as errors for C++ mode
  • Added IncompatibleFunctionPointer
Feb 14 2020, 9:36 AM · Restricted Project

Feb 12 2020

Anastasia updated the diff for D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.

If I reuse the helper checkPointerTypesForAssignment I end up with lots of error turned into warnings, see example in
test/SemaCXX/addr-of-overloaded-function.cpp

Feb 12 2020, 4:50 AM · Restricted Project

Feb 7 2020

Anastasia committed rG6064f426a183: [OpenCL] Restrict addr space conversions in nested pointers (authored by Anastasia).
[OpenCL] Restrict addr space conversions in nested pointers
Feb 7 2020, 4:08 AM
Anastasia closed D73360: [OpenCL] Restrict address space conversions in nested pointers.
Feb 7 2020, 4:07 AM · Restricted Project
Anastasia added a comment to D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.

Hmm. The alternative approach, I suppose, would be to recognize that we're about to emit a generic error and just recheck assignment constraints to recompute the AssignConvertType.

Feb 7 2020, 2:56 AM · Restricted Project

Feb 6 2020

Anastasia added a comment to D73360: [OpenCL] Restrict address space conversions in nested pointers.

Okay, we can go with this for now, since it does fix a bug.

Feb 6 2020, 3:36 AM · Restricted Project
Anastasia created D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 6 2020, 3:36 AM · Restricted Project
Anastasia updated the summary of D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 6 2020, 3:36 AM · Restricted Project

Feb 5 2020

Anastasia accepted D73651: [OpenCL][CUDA][HIP][SYCL] Add norecurse.

LGTM! Thanks!

Feb 5 2020, 5:23 AM · Restricted Project

Feb 4 2020

Anastasia updated the diff for D73360: [OpenCL] Restrict address space conversions in nested pointers.

Add warning into IncompatiblePointerTypesDiscardsQualifiers group.

Feb 4 2020, 5:56 AM · Restricted Project
Anastasia added a comment to D73360: [OpenCL] Restrict address space conversions in nested pointers.

If it's reasonable to persist the failure kind, that would probably be good, but it might be a lot of work.

Feb 4 2020, 3:14 AM · Restricted Project
Anastasia added inline comments to D73651: [OpenCL][CUDA][HIP][SYCL] Add norecurse.
Feb 4 2020, 3:05 AM · Restricted Project

Jan 31 2020

Anastasia added a comment to D73360: [OpenCL] Restrict address space conversions in nested pointers.

Is there no follow-up code when actually emitting the failure diagnostic which tries to figure out a more specific cause of failure?

Jan 31 2020, 7:02 AM · Restricted Project

Jan 30 2020

Anastasia added inline comments to D73360: [OpenCL] Restrict address space conversions in nested pointers.
Jan 30 2020, 3:51 AM · Restricted Project

Jan 28 2020

Anastasia added a comment to D71460: [OpenCL] Fix support for cl_khr_mipmap_image_writes.

Adding @svenvh mainly to check if any fix is needed for the TableGen BIFs too?

Jan 28 2020, 9:44 AM · Restricted Project
Anastasia accepted D71460: [OpenCL] Fix support for cl_khr_mipmap_image_writes.

LGTM! Thanks!

Jan 28 2020, 9:41 AM · Restricted Project

Jan 24 2020

Anastasia created D73360: [OpenCL] Restrict address space conversions in nested pointers.
Jan 24 2020, 8:15 AM · Restricted Project

Jan 3 2020

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

Jan 2 2020

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

Recovered lost bit of information.

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

Dec 27 2019

Anastasia committed rG752220ea2664: [OpenCL] Fixed printing of __private in AMDGPU test (authored by Anastasia).
[OpenCL] Fixed printing of __private in AMDGPU test
Dec 27 2019, 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?

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

LGTM! Thanks!

Dec 27 2019, 8:03 AM · Restricted Project
Anastasia committed rG869d17d851ba: [OpenCL] Pretty print __private addr space (authored by Anastasia).
[OpenCL] Pretty print __private addr space
Dec 27 2019, 5:44 AM
Anastasia closed D71272: [OpenCL] Pretty print __private addr space.
Dec 27 2019, 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