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 (289 w, 22 h)

Recent Activity

Fri, Aug 28

Anastasia closed D86626: [OpenCL][Docs] 10.x release notes.

https://reviews.llvm.org/rGdae9fe408793def8a49f5e1d10d2a859627785e3

Fri, Aug 28, 3:29 AM
Anastasia updated subscribers of D86626: [OpenCL][Docs] 10.x release notes.

@hans, would you be able to commit this to the release branch?

Fri, Aug 28, 12:26 AM

Thu, Aug 27

Anastasia added a comment to D62574: Add support for target-configurable address spaces..

This change looks good to me in general conceptually as it is completing missing logic in clang that let's targets to customize the address space behavior!

Thu, Aug 27, 9:35 AM · Restricted Project

Wed, Aug 26

Anastasia updated the diff for D86626: [OpenCL][Docs] 10.x release notes.

Fixed extra space

Wed, Aug 26, 8:21 AM
Anastasia updated the diff for D86626: [OpenCL][Docs] 10.x release notes.
  • Addressed comments from Sven.
Wed, Aug 26, 8:19 AM
Anastasia requested review of D86626: [OpenCL][Docs] 10.x release notes.
Wed, Aug 26, 7:52 AM

Aug 13 2020

Anastasia added a comment to D62574: Add support for target-configurable address spaces..

I think this works now. It should probably be given a few more reviewers to have a look. Do you have some suggestions, @Anastasia ?

Aug 13 2020, 4:20 AM · Restricted Project

Aug 12 2020

Anastasia committed rG3c8a4ee0764c: [OpenCL] Remove warning for variadic macros in C++ for OpenCL. (authored by Anastasia).
[OpenCL] Remove warning for variadic macros in C++ for OpenCL.
Aug 12 2020, 8:19 AM
Anastasia closed D85429: [OpenCL] Allow for variadic macros in C++ for OpenCL.
Aug 12 2020, 8:19 AM · Restricted Project

Aug 11 2020

Anastasia accepted D85429: [OpenCL] Allow for variadic macros in C++ for OpenCL.

LGTM! Thanks

Aug 11 2020, 3:15 AM · Restricted Project

Aug 6 2020

Anastasia added a comment to D85429: [OpenCL] Allow for variadic macros in C++ for OpenCL.

Can you extend test test/Preprocessor/macro_variadic.cl to cover C++ for OpenCL mode, otherwise LGTM!

Aug 6 2020, 8:03 AM · Restricted Project

Aug 5 2020

Anastasia added inline comments to D82756: Port some floating point options to new option marshalling infrastructure.
Aug 5 2020, 4:09 AM · Restricted Project, Restricted Project

Jul 29 2020

Anastasia added a comment to D62574: Add support for target-configurable address spaces..

This was also only an initial concept. I think that even once all the issues with the patch have been ironed out, it would require a round of wider review since it's a fairly hefty API change.

Jul 29 2020, 3:23 PM · Restricted Project
Anastasia added a comment to D62574: Add support for target-configurable address spaces..

It seems that D70605 attempted to ameliorate the issues that I observed (pointer-conversion doing too much), but it didn't manage to solve the problem fully.

Jul 29 2020, 3:16 PM · Restricted Project

Jul 28 2020

Anastasia accepted D82174: [OpenCL] Add global_device and global_host address spaces.

LGTM, Thanks! Although I left a comment about possible test simplification that can be addressed before committing.

Jul 28 2020, 1:06 PM · Restricted Project

Jul 27 2020

Anastasia committed rG92fa91bb4029: [OpenCL] Fixed missing address space for templated copy constructor. (authored by Anastasia).
[OpenCL] Fixed missing address space for templated copy constructor.
Jul 27 2020, 7:22 AM
Anastasia closed D83665: [OpenCL] Fixed missing address space for templated copy constructor.
Jul 27 2020, 7:21 AM · Restricted Project

Jul 24 2020

Anastasia accepted D83665: [OpenCL] Fixed missing address space for templated copy constructor.

LGTM! Thanks

Jul 24 2020, 5:47 AM · Restricted Project

Jul 20 2020

Anastasia added inline comments to D83665: [OpenCL] Fixed missing address space for templated copy constructor.
Jul 20 2020, 10:20 AM · Restricted Project

Jul 17 2020

Anastasia added inline comments to D83665: [OpenCL] Fixed missing address space for templated copy constructor.
Jul 17 2020, 10:24 AM · Restricted Project
Anastasia added inline comments to D82174: [OpenCL] Add global_device and global_host address spaces.
Jul 17 2020, 9:56 AM · Restricted Project
Anastasia added inline comments to D82756: Port some floating point options to new option marshalling infrastructure.
Jul 17 2020, 9:46 AM · Restricted Project, Restricted Project

Jul 13 2020

Anastasia committed rG6050c156ab4f: [OpenCL] Defer addr space deduction for dependent type. (authored by Anastasia).
[OpenCL] Defer addr space deduction for dependent type.
Jul 13 2020, 3:46 AM
Anastasia closed D82781: [OpenCL] Fix missing address space deduction in template variables.
Jul 13 2020, 3:46 AM · Restricted Project

Jul 10 2020

Anastasia committed rG8c8a2fd1f015: [OpenCL] Fixed typo for ctor stub name in UsersManual (authored by Anastasia).
[OpenCL] Fixed typo for ctor stub name in UsersManual
Jul 10 2020, 11:05 AM

Jul 8 2020

Anastasia added inline comments to D82756: Port some floating point options to new option marshalling infrastructure.
Jul 8 2020, 6:31 AM · Restricted Project, Restricted Project
Anastasia accepted D82781: [OpenCL] Fix missing address space deduction in template variables.

LGTM! Thanks!

Jul 8 2020, 4:53 AM · Restricted Project

Jul 3 2020

Anastasia added inline comments to D82781: [OpenCL] Fix missing address space deduction in template variables.
Jul 3 2020, 11:17 AM · Restricted Project
Anastasia added inline comments to D82174: [OpenCL] Add global_device and global_host address spaces.
Jul 3 2020, 11:17 AM · Restricted Project

Jun 29 2020

Anastasia added a comment to D82781: [OpenCL] Fix missing address space deduction in template variables.

So if I understand this correctly when the template is instantiated we don't have QualType with the address space deduced initially during parsing of a template global variable?

Jun 29 2020, 9:42 AM · Restricted Project

Jun 26 2020

Anastasia added inline comments to D82174: [OpenCL] Add global_device and global_host address spaces.
Jun 26 2020, 3:46 AM · Restricted Project
Anastasia accepted D82313: [OpenCL] Reject block arguments.

LGTM! Thanks!

Jun 26 2020, 3:13 AM · Restricted Project

Jun 23 2020

Anastasia added a comment to D82174: [OpenCL] Add global_device and global_host address spaces.

TODO: update address space numerical values for SPIR target
Regarding the TODO. Still I like an idea of detached address spaces a little bit more, but I see your point. I would love to check how it works with SPIR-V address space mapping in SPIR-V to LLVM IR translator. I know, it shall have a little impact on a clang work, but still what to see the work I have to do there first (5 and 6 are already occupied there).

Jun 23 2020, 10:43 AM · Restricted Project
Anastasia added inline comments to D82313: [OpenCL] Reject block arguments.
Jun 23 2020, 10:10 AM · Restricted Project

Jun 19 2020

Anastasia added inline comments to D82174: [OpenCL] Add global_device and global_host address spaces.
Jun 19 2020, 8:08 AM · Restricted Project
Anastasia added inline comments to D82174: [OpenCL] Add global_device and global_host address spaces.
Jun 19 2020, 8:05 AM · Restricted Project
Anastasia added a comment to D82174: [OpenCL] Add global_device and global_host address spaces.

Btw could you upload a full diff, please?
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
It will simplify the review....

Jun 19 2020, 8:05 AM · Restricted Project
Anastasia added a comment to D82174: [OpenCL] Add global_device and global_host address spaces.

I think you should also test the conversions of address spaces and it would be good to add a cl file i.e. OpenCL C level test.

Jun 19 2020, 7:32 AM · Restricted Project

Jun 18 2020

Anastasia added a comment to D68994: [RFC] Redefine `convergent` in terms of dynamic instances.

What is the status of this change?

I still want to pursue a proper modeling of convergent that would probably express that the invalid optimizations that you're likely to see are forbidden. However, the model described here has some issues, and I hope to introduce a slight variation that addresses those issue.

As a matter of pragmatism, I wonder whether we shouldn't just already disable those problematic optimizations today...

Jun 18 2020, 9:13 AM · Restricted Project

Jun 11 2020

Anastasia accepted D81608: Fix incorrect call to ExprResult::get().

LGTM! Thanks! Great spot!

Jun 11 2020, 1:47 PM · Restricted Project

Jun 10 2020

Anastasia updated subscribers of D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

@Anastasia, if we make this change specific to SYCL mode, will it address your concerns?

I can't answer this question for the reasons I have explained above.

Sorry, I'm not sure that I get your concern correctly, so let me clarify: is it allowing conversion between pointers w/ and w/o address space annotation in non-SYCL mode or using OpenCL address space attributes in SYCL mode?

Just to help you to understand the proposed design, I created the full patch for address space handling in SYCL: https://github.com/bader/llvm/pull/18. There are few CodeGen tests validating LLVM IR for SPIR target. Fee free to ask any questions on this PR.

Jun 10 2020, 12:13 PM · Restricted Project

Jun 8 2020

Anastasia added a comment to D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

@Anastasia, if we make this change specific to SYCL mode, will it address your concerns?

Jun 8 2020, 12:41 PM · Restricted Project

Jun 4 2020

Anastasia added a comment to D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

Why? Can you explain what you are trying to achieve with this?

I think @asavonic can provide more detailed answer, but IIRC we spent a lot time trying to marry template meta-programming with OpenCL address space deductions, but even simplest template functions from C++ standard library breaks compilation. It's important to note one important difference in design goals for SYCL and C++ for OpenCL. SYCL aims to enable compilation of regular C++ as much as possible where as one of the C++ for OpenCL goals is to keep compatibility with OpenCL C. These two goals might lead to different design decisions.

I don't see a contradiction in those goals. We plan to support C++ libraries with C++ for OpenCL of course with functionality that is accepted by conformant OpenCL implementations. For example, libraries that use virtual functions leading to function pointers are not going to work portably in OpenCL devices. If SYCL aims to compile to conformant OpenCL devices then it should not be very different I imagine?

(Edited a bit)

There is a fundamental difference (given the direction taken for OpenCL), OpenCL mode actively modifies user's types (C and C++ for OpenCL AFAIK). So inside a function, this:

int var;

becomes

VarDecl  var '__private int'

Which is fine in C where you can't really do much with your types, but this has a massive and destructive effect in C++. For instance this does not compile in C++ for OpenCL:

void foo() {
    int var; // '__private int' not 'int'
    int* ptr1 = &var; // '__generic int* __private' not 'int*'
    decltype(var)* ptr2 = ptr1; // error: cannot initialize a variable of type 'decltype(var) *__private' (aka '__private int *__private') with an lvalue of type '__generic int *__private'
}
Jun 4 2020, 2:57 PM · Restricted Project
Anastasia added a comment to D77220: [SYCL] Enable Open CL types required for implementing the SYCL headers..

Seems reasonable from the OpenCL side.

Jun 4 2020, 5:57 AM
Anastasia committed rG4a4402f0d721: [OpenCL] Add cl_khr_extended_subgroup extensions. (authored by Anastasia).
[OpenCL] Add cl_khr_extended_subgroup extensions.
Jun 4 2020, 5:32 AM
Anastasia closed D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
Jun 4 2020, 5:30 AM · Restricted Project

Jun 3 2020

Anastasia added a comment to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.

Great! Thanks! Feel free to go ahead and commit this!

Thanks. Can someone commit this for me, please? Also to 10.0 if possible?

Jun 3 2020, 1:10 PM · Restricted Project
Anastasia requested changes to D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

Why? Can you explain what you are trying to achieve with this?

I think @asavonic can provide more detailed answer, but IIRC we spent a lot time trying to marry template meta-programming with OpenCL address space deductions, but even simplest template functions from C++ standard library breaks compilation. It's important to note one important difference in design goals for SYCL and C++ for OpenCL. SYCL aims to enable compilation of regular C++ as much as possible where as one of the C++ for OpenCL goals is to keep compatibility with OpenCL C. These two goals might lead to different design decisions.

Jun 3 2020, 1:10 PM · Restricted Project

Jun 2 2020

Anastasia added a comment to D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

Default address space is normally an address space of automatic storage i.e. private in OpenCL. If you look at the address space map of targets most of them map default and private address spaces to the same value. Converting between private and other named address space is not allowed in OpenCL see section 6.5. I don't believe this change is doing anything legitimate.

Jun 2 2020, 8:14 AM · Restricted Project

Jun 1 2020

Anastasia accepted D80574: [ExtVector] Support ExtVectorType conditional operator.

LGTM! Thanks! Please address small documentation nitpick before committing...

Jun 1 2020, 12:59 PM · Restricted Project
Anastasia accepted D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.

Bumped the OpenCL version from 1.2 to 2.0.

Jun 1 2020, 7:28 AM · Restricted Project
Anastasia updated subscribers of D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
Jun 1 2020, 6:55 AM · Restricted Project

May 29 2020

Anastasia accepted D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.

LGTM! Thanks!

May 29 2020, 9:12 AM · Restricted Project
Anastasia added inline comments to D80574: [ExtVector] Support ExtVectorType conditional operator.
May 29 2020, 8:39 AM · Restricted Project
Anastasia added inline comments to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
May 29 2020, 7:34 AM · Restricted Project

May 28 2020

Anastasia abandoned D80440: [OpenCL] Prevent fused mul and add by default.
May 28 2020, 9:15 AM
Anastasia added inline comments to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
May 28 2020, 8:42 AM · Restricted Project
Anastasia added inline comments to D80574: [ExtVector] Support ExtVectorType conditional operator.
May 28 2020, 8:07 AM · Restricted Project

May 22 2020

Anastasia created D80440: [OpenCL] Prevent fused mul and add by default.
May 22 2020, 8:01 AM
Anastasia added inline comments to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 22 2020, 8:01 AM
Anastasia added inline comments to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 22 2020, 5:18 AM
Anastasia added inline comments to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 22 2020, 5:18 AM
Anastasia added a comment to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.

The langref wording makes me think this isn't quite right. This depends on your definition of floating point contraction. I've always assumed it meant allow FMA, potentially increasing precision. Is contracting into something less precise allowed?

May 22 2020, 3:00 AM

May 21 2020

Anastasia retitled D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable from [RCF][OpenCL] Set fp contract flag on -cl-mad-enable to [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 21 2020, 3:43 PM
Anastasia added inline comments to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 21 2020, 3:43 PM
Anastasia created D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 21 2020, 3:43 PM
Anastasia added inline comments to D80315: Fix CC1 command line options mapping into fast-math flags..
May 21 2020, 1:32 PM · Restricted Project
Anastasia added inline comments to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
May 21 2020, 12:59 PM · Restricted Project

May 20 2020

Anastasia updated subscribers of D80317: [SYCL] Prohibit arithmetic operations for incompatible pointers.
May 20 2020, 2:18 PM · Restricted Project

May 19 2020

Anastasia updated subscribers of D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
May 19 2020, 5:54 AM · Restricted Project

May 18 2020

Anastasia added inline comments to D79903: FastMathFlags.allowContract should be init from FPFeatures.allowFPContractAcrossStatement.
May 18 2020, 1:33 PM · Restricted Project
Anastasia added a comment to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.

Can you please add a reference to the document that described these extensions in the description of your patch. Thanks!

May 18 2020, 1:01 PM · Restricted Project
Anastasia committed rGa6a237f2046a: [OpenCL] Added addrspace_cast operator in C++ mode. (authored by Anastasia).
[OpenCL] Added addrspace_cast operator in C++ mode.
May 18 2020, 4:15 AM
Anastasia closed D60193: [OpenCL] Added addrspace_cast operator.
May 18 2020, 4:15 AM · Restricted Project

May 10 2020

Anastasia added inline comments to D60193: [OpenCL] Added addrspace_cast operator.
May 10 2020, 2:54 PM · Restricted Project
Anastasia updated the diff for D60193: [OpenCL] Added addrspace_cast operator.
  • Improved behavior by allowing casting between equivalent types.
  • Improved formatting.
  • Improved tests.
May 10 2020, 2:54 PM · Restricted Project

May 6 2020

Anastasia added inline comments to D60193: [OpenCL] Added addrspace_cast operator.
May 6 2020, 3:19 PM · Restricted Project
Anastasia added a comment to D60193: [OpenCL] Added addrspace_cast operator.

When compiling this I get the following warning:

clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:1213:10: warning: enumeration value 'CXXAddrspaceCastExprClass' not handled in switch

The fix is probably to just add the missing case with the other *CastExprClass cases.

There's also a similar warning for clang/tools/libclang/CXCursor.cpp:132.

May 6 2020, 2:44 PM · Restricted Project
Anastasia updated the diff for D60193: [OpenCL] Added addrspace_cast operator.

Sorry for long latency. I have rebased the patch to the current master and addressed the comments from @mantognini too.

May 6 2020, 2:44 PM · Restricted Project

May 4 2020

Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

Would it not become confusing since the builtins are going to be included by default? Should we rename the flag at least? Also ideally it should be documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header

ah I guess if we leave it under -cc1 we will have the command line interface as follows:

  • Driver (without -cc1) adds OpenCL header by default that can be overridden by the flag added in this patch.
  • Frontend (with -cc1) doesn't add the header by default but there are two flags -fdeclare-opencl-builtins or -finclude-default-header that allow to include the header.

The name of -fdeclare-opencl-builtins becomes a bit non-intuitive, a more intuitive name would be something like -fopencl-tablegen-builtins perhaps or -fopencl-fast-builtins if we don't want to mention TableGen. But since it is still an experimental option, I have no objections against postponing the renaming until the option has reached maturity.

I vote for -fopencl-fast-builtins.

The main problem I'm trying to solve is that users shouldn't need to concern themselves with including any header, much less a choice between two internal implementation details. Switching the two internal header implementations seems OK to leave as a cc1 flag. The main question I think is what the spelling of how to disable whatever default header was chosen, and what the internal flags to switch the implementation look like.

So what's the agreement on spelling? Use -nostdinc/-nostdlib? Have 2 different cc1 flags for the header implementation switch? Surface/invert -fno-include-default-header?

May 4 2020, 9:37 AM

Apr 30 2020

Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

I'm also wondering if using -nogpulib for the corresponding linker purpose was correct, since in the OpenCL case it's not really an offload target. Maybe this should switch to -nostdlib?

-nogpulib is fine since opencl compiler is in parallel with the device compiler of CUDA/HIP. The library it uses is the device library.

OpenCL can target other devices than GPUs, including CPUs and FPGAs, referring to gpulibs wrt opencl is a misnomer.

It would be nice to have some clarity as to how OpenCL is handled wrt clang frontend vs. clang driver.
OpenCL options are currently split between the two (e.g. cl-denorms-are-zero is only available in the driver and not the frontend)
There are 3 implementations of CL headers, two in clang which might or might not be included by default, and the 3rd one in libclc.

Apr 30 2020, 11:47 AM

Apr 29 2020

Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

ah I guess if we leave it under -cc1 we will have the command line interface as follows:

  • Driver (without -cc1) adds OpenCL header by default that can be overridden by the flag added in this patch.
  • Frontend (with -cc1) doesn't add the header by default but there are two flags -fdeclare-opencl-builtins or -finclude-default-header that allow to include the header.

Is my understanding correct? We should reflect this is the User Manual.

I think -finclude-default-header -fno-include-default-header better becomes both driver and -cc1 option since users are likely to use it with driver. It may also be used with other languages e.g. HIP.

Apr 29 2020, 12:21 PM
Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

Would it not become confusing since the builtins are going to be included by default? Should we rename the flag at least? Also ideally it should be documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header

ah I guess if we leave it under -cc1 we will have the command line interface as follows:

  • Driver (without -cc1) adds OpenCL header by default that can be overridden by the flag added in this patch.
  • Frontend (with -cc1) doesn't add the header by default but there are two flags -fdeclare-opencl-builtins or -finclude-default-header that allow to include the header.

The name of -fdeclare-opencl-builtins becomes a bit non-intuitive, a more intuitive name would be something like -fopencl-tablegen-builtins perhaps or -fopencl-fast-builtins if we don't want to mention TableGen. But since it is still an experimental option, I have no objections against postponing the renaming until the option has reached maturity.

Apr 29 2020, 12:21 PM

Apr 28 2020

Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

I am looping in @svenvh to discuss this further. Sven, do you think we should rename this flag due to current proposed change? Should it be moved out of -cc1 too?

I would leave -fdeclare-opencl-builtins as it is, until it is complete and taken out of its "experimental" status. Then we can discuss if we want to use TableGen instead of the header as a default.

Would it not become confusing since the builtins are going to be included by default? Should we rename the flag at least? Also ideally it should be documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header

Apr 28 2020, 6:56 AM
Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

I am looping in @svenvh to discuss this further. Sven, do you think we should rename this flag due to current proposed change? Should it be moved out of -cc1 too?

I would leave -fdeclare-opencl-builtins as it is, until it is complete and taken out of its "experimental" status. Then we can discuss if we want to use TableGen instead of the header as a default.

Would it not become confusing since the builtins are going to be included by default? Should we rename the flag at least? Also ideally it should be documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header

Apr 28 2020, 6:24 AM
Anastasia committed rGfe667e8522a6: [OpenCL] Fixed test for the cast operators. (authored by Anastasia).
[OpenCL] Fixed test for the cast operators.
Apr 28 2020, 4:47 AM
Herald added a project to D77923: OpenCL: Fix some missing predefined macros: Restricted Project.

The current solution seems very specific and doesn't provide generic uniform mechanisms for the targets. Would something based on a triple component not work?

Apr 28 2020, 4:15 AM · Restricted Project
Anastasia updated subscribers of D78979: OpenCL: Include builtin header by default.

I'm somewhat confused by the way this is supposed to work, or why a
separate option exists for OpenCL. The other language flags seem to be
implemented in the driver, not cc1 like OpenCL. I'm not sure this is
the right set of flag naming decisions, or if we really need the
fno-include-default-header cc1 flag.

Apr 28 2020, 3:43 AM
Anastasia accepted D78777: [AST] Use PrintingPolicy for format string diagnosis.

LGTM! Thanks!

Apr 28 2020, 3:11 AM · Restricted Project

Apr 14 2020

Anastasia added a comment to D77923: OpenCL: Fix some missing predefined macros.

As for OpenCL C spec we should ideally add __OPENCL_VERSION__ but I feel it should be taken from architecture or OS type... I think there were other cases where we needed something like an OpenCL runtime version in the triple too but I can't remember this now.

Apr 14 2020, 8:32 AM · Restricted Project

Mar 26 2020

Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Mar 26 2020, 6:28 AM · Restricted Project
Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Mar 26 2020, 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.

Mar 26 2020, 5:55 AM

Mar 25 2020

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.

Mar 25 2020, 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!

Mar 25 2020, 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.

Mar 25 2020, 9:43 AM

Mar 23 2020

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

Mar 12 2020

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

Mar 10 2020

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