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

Recent Activity

Wed, Nov 24

Anastasia added inline comments to D112230: [OpenCL] Add support of __opencl_c_device_enqueue feature macro..
Wed, Nov 24, 7:18 AM · Restricted Project

Tue, Nov 23

Anastasia added a comment to D110618: [HIPSPV][2/4] Add HIPSPV tool chain.

Could you please clarify the interface to SPIRV-LLVM-Translator tool, specifically:

  • Does clang lookup the path to the translator or assume any default path?
  • Is there any diagnostic provided if the translator not installed/found?
  • How does clang synchronize with the translator versions i.e. some LLVM IR might not be ingested by certain version of the translator. Would this results in the translator ICE or error in the translator, or is it something that can be diagnosed early by clang or during clang build/installation?
Tue, Nov 23, 3:45 AM · Restricted Project
Anastasia accepted D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.

LGTM! Thanks

Tue, Nov 23, 2:58 AM · Restricted Project, Restricted Project

Mon, Nov 8

Anastasia added a comment to D110184: [OpenCL] Constructor address space test adjusted for C++ for OpenCL 2021.

Ping, @Topotuna do you still plan to commit this?

Mon, Nov 8, 5:57 AM · Restricted Project
Anastasia added a comment to D110036: [TargetInfo][LangOpts] Refactor target info and language options adjustment..

Just to elaborate on the problem that is being solved. We have ended up with cycling dependencies between LangOptions and TargetInfo i.e. some language options became dependent on the target and vice versa.

Mon, Nov 8, 5:56 AM · Restricted Project
Anastasia added a comment to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

FYI the original RFC is https://lists.llvm.org/pipermail/cfe-dev/2021-August/068603.html

Mon, Nov 8, 5:38 AM · Restricted Project, Restricted Project
Anastasia committed rGa10a69fe9c74: [SPIR-V] Add SPIR-V triple and clang target info. (authored by Anastasia).
[SPIR-V] Add SPIR-V triple and clang target info.
Mon, Nov 8, 5:34 AM
Anastasia closed D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.
Mon, Nov 8, 5:34 AM · Restricted Project, Restricted Project
Anastasia added a comment to D112230: [OpenCL] Add support of __opencl_c_device_enqueue feature macro..

@Anastasia, @yaxunl, do you think it's possible to refactor code generation for blocks such that block literal for global blocks (with no captures) would be emitted in constant address space? Now it's emitted in global address space (for example @__block_literal_global in https://godbolt.org/z/4z8hGj7hz).

Mon, Nov 8, 4:57 AM · Restricted Project
Anastasia added inline comments to D112110: [OpenCL] queue_t and ndrange_t can't be defined in program scope..
Mon, Nov 8, 4:06 AM · Restricted Project
Anastasia added inline comments to D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.
Mon, Nov 8, 4:01 AM · Restricted Project, Restricted Project

Oct 26 2021

Anastasia added a comment to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

Thanks for the clarifications. So it seems that you are not expecting that the device target triple is being explicitly passed anywhere then and that means you pass the device triple implicitly?

We are meaning to use the --offload as a way to pass device target triple explicitly.

Although your --offload option does seem conceptually like a device target triple, so I wonder if better naming for it would be --offload-target? Would it work for you if we introduce SPIR-V triple explicitly and you use it as a device offload triple?

To introduce a way to pass a device target triple in HIP compilation, we decided it to be aligned with the envisioned “Unified Offload Option” feature [1] to avoid overlap with similar concept. The design of the feature is pending. AFAIK, @yaxunl, who is working on it, hasn't got time yet to continue the work. In D110622 we propose adding the --offload option as partial implementation and there is a bit of discussion about the design too.

It would probably makes sense to use the same triple to targeting SPIR-V generation by everyone?

Yes, it makes sense.

However I appreciate that OpenCL flow would be somewhat different since it doesn't have a split into host and device but only contains device compilation phase...

The split is specific to offloading languages (such as CUDA, HIP and OpenMP) whose compilation flow is different from the traditional compilation flow. The traditional compilation flow used for non-offloading languages naturally does not have the host/device compilation split.

Oct 26 2021, 12:43 PM · Restricted Project, Restricted Project
Anastasia added inline comments to D112110: [OpenCL] queue_t and ndrange_t can't be defined in program scope..
Oct 26 2021, 12:39 PM · Restricted Project
Anastasia added a comment to D112410: [SPIR-V] Add a tool chain for SPIR-V (incomplete).

Cool. I like the direction... In the end it probably makes sense to separate clang compilation flow into more separate steps. This makes it more suitable to non-LLVM based backends or even MLIR towards Clang Intermediate Language. This looks like a fairly good starting point! Thanks!

Oct 26 2021, 12:15 PM · Restricted Project
Anastasia added a comment to D112404: [SPIR-V] Add translator tool.

This direction of creating a common translator tool makes sense to me! Thanks!

Oct 26 2021, 12:05 PM · Restricted Project

Oct 14 2021

Anastasia added a comment to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

Can you explain what does this mean

It was trying to clarify a potential misunderstanding of how programs are compiled when HIPSPV is targeted: For HIPSPV, the SPIR-V code generation is done by the clang driver. When we compile HIP programs for HIPCL or the HIPLZ runtime, we issue a single clang command such as this:

clang++ --offload=spirv64 foo.hip -l<hip-runtime> -o foo

With this, the clang driver compiles the device side code to a SPIR-V binary and then compiles host side code, and embeds the SPIR-V binary to the host (fat) binary.

? In the tests I can see the following --offload=spirv64 which does feel like it is specified explicitly that the target is SPIR-V...

For HIPSPV the --offload option is used to specify the device code target but the end result is a host binary (e.g. x86_64) with device code (SPIR-V binary) embedded in it. We need a way to specify the device code target to be other than the currently fixed amdgcn-amd-amdhsa and using the --offload switch is a solution we are suggesting here.

Oct 14 2021, 5:48 AM · Restricted Project, Restricted Project

Oct 13 2021

Anastasia added a comment to D110618: [HIPSPV][2/4] Add HIPSPV tool chain.

I don't feel it is different for OpenCL though... I am not in favour of repeating the same functionality for every language since the requirement will be likely identical. There is no timeline for when this functionality will be dropped so we have to assume that even though temporary it might be a solution for long enough.

If it is likely the SPIR-V backend won’t land soon and it is expected that also other languages might benefit from the calls to the llvm-spirv tool, the functionality to do so would be better placed in a more generally useful place. Do you have suggestions where this functionality could be moved?

I believe it concerns mostly the call to the llvm-spriv (this is sought in PATH, not given via a command line parameter) inside constructEmitSpirvCommand(). This could be extracted to another function in a utility library so it could be accessed by other languages/tools in the future. Does it sound OK?

Oct 13 2021, 10:23 AM · Restricted Project
Anastasia added a comment to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

I would like to explain the position of the OpenCL tooling community and the directions we would like to take with SPIR-V support in LLVM. We believe that SPIR-V triple and target should be added explicitly to LLVM/Clang for the following reasons:

Oct 13 2021, 8:13 AM · Restricted Project, Restricted Project
Anastasia added a comment to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

> What I have in mind is to continue using SPIR target for now (until SPIR-V back-end is added).

For instance, SYCL compiler emits code for SPIR target and code format is configured via flag.

-emit-llvm changes output file format for regular C++ compilation flow:

clang++ a.cpp -c -o a.o                      # object format by default 
clang++ a.cpp -c -emit-llvm -o a.bc          # LLVM IR format with `-emit-llvm`

Similar approach for HIP device compilation flow:

clang++ -target spir -x hip a.cpp -cuda-device-only -o a.spv                 # SPIR-V format by default
clang++ -target spir -x hip a.cpp -cuda-device-only -emit-llvm -o a.bc       # LLVM IR (aka SPIR) format with `-emit-llvm` if needed

I think this was proposed in RFC. @linjamaki, am I right?

In the RFC we proposed a HIP compilation flow for producing and embedding SPIR-V binary into the host executable. What was not stated in the RFC clearly is that the process is supposed to be carried out without the need for clients to issue explicit commands for producing SPIR-V binaries and then to link them into the final executable separately. D110622 has test cases as examples for this.

Oct 13 2021, 4:04 AM · Restricted Project, Restricted Project

Oct 6 2021

Anastasia added a comment to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.
  1. Implementing SPIR-V target as SPIR target. @bader do you suggest that we add spirv triple to clang and map it into SPIR taget or do you suggest something different?

What I have in mind is to continue using SPIR target for now (until SPIR-V back-end is added).
For instance, SYCL compiler emits code for SPIR target and code format is configured via flag.

-emit-llvm changes output file format for regular C++ compilation flow:

clang++ a.cpp -c -o a.o                      # object format by default 
clang++ a.cpp -c -emit-llvm -o a.bc          # LLVM IR format with `-emit-llvm`

Similar approach for HIP device compilation flow:

clang++ -target spir -x hip a.cpp -cuda-device-only -o a.spv                 # SPIR-V format by default
clang++ -target spir -x hip a.cpp -cuda-device-only -emit-llvm -o a.bc       # LLVM IR (aka SPIR) format with `-emit-llvm` if needed

I think this was proposed in RFC. @linjamaki, am I right?

Oct 6 2021, 11:18 AM · Restricted Project, Restricted Project
Anastasia added a comment to D110685: [HIPSPV][4/4] Add option to use llc to emit SPIR-V.

Ok, is the idea to deprecate this flag once we switch to llc by default then?

Oct 6 2021, 3:52 AM · Restricted Project
Anastasia added a comment to D110618: [HIPSPV][2/4] Add HIPSPV tool chain.

Considering that SPIR-V translation step is also required for other languages would it make sense to add llvm-spirv as a common tool like for example C/C++ linkers and create a bit of common infrastructure? It might be something we can do as a separate step too but it would be good to make sure nothing prevents us from doing this in the future... We should probably also think about the command line interface unification as it probably doesn't make sense for every language to add their own flags for locating SPIR-V translator.

I don’t think it would work out well. llvm-spirv (or other tool relying on LLVM bitcode input) and LLVM may have version differences that cause obscure error cases - like newer LLVM producing bitcode with new features the tools are not expecting and ready for them. The usage of llvm-spirv tool in the HIPSPV tool chain is not intended to be a longer term solution due to this shortcoming.

Oct 6 2021, 2:54 AM · Restricted Project
Anastasia added inline comments to D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.
Oct 6 2021, 2:46 AM · Restricted Project, Restricted Project

Oct 5 2021

Anastasia added a comment to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

It would be good to get closure on this asap.

@bader We had related discussions on the other reviews about the approach in this patch. If you have any concerns/suggestions can you please notify asap...

Sorry for the delay. I was on vacation last week. I've added my concerns to the discussion in https://reviews.llvm.org/D108621.

Oct 5 2021, 4:40 AM · Restricted Project, Restricted Project
Anastasia added inline comments to D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.
Oct 5 2021, 4:19 AM · Restricted Project, Restricted Project

Sep 30 2021

Anastasia added a comment to D110618: [HIPSPV][2/4] Add HIPSPV tool chain.

Considering that SPIR-V translation step is also required for other languages would it make sense to add llvm-spirv as a common tool like for example C/C++ linkers and create a bit of common infrastructure? It might be something we can do as a separate step too but it would be good to make sure nothing prevents us from doing this in the future... We should probably also think about the command line interface unification as it probably doesn't make sense for every language to add their own flags for locating SPIR-V translator.

Sep 30 2021, 3:23 AM · Restricted Project
Anastasia added a comment to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

It would be good to get closure on this asap.

Sep 30 2021, 2:50 AM · Restricted Project, Restricted Project

Sep 22 2021

Anastasia accepted D110184: [OpenCL] Constructor address space test adjusted for C++ for OpenCL 2021.

LGTM! Thanks

Sep 22 2021, 2:35 AM · Restricted Project
Anastasia added inline comments to D109818: [HIPSPV] Convert HIP kernels to SPIR-V kernels.
Sep 22 2021, 2:34 AM · Restricted Project

Sep 21 2021

Anastasia added inline comments to D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.
Sep 21 2021, 9:52 AM · Restricted Project, Restricted Project
Anastasia accepted D110155: [OpenCL] Allow optional __generic in __remove_address_space utility.

LGTM! Thanks

Sep 21 2021, 8:35 AM · Restricted Project
Anastasia accepted D108359: [clang][NFC] Fix needless double-parenthisation.

LGTM! Thanks

Sep 21 2021, 3:44 AM · Restricted Project
Anastasia accepted D109874: [OpenCL] Defines helper function for OpenCL default address space.

Feel free to adjust the naming scheme either in the same commit or separately.

Sep 21 2021, 3:42 AM · Restricted Project
Anastasia added a comment to D109874: [OpenCL] Defines helper function for OpenCL default address space.

Both comments addressed. Personally, I would shuffle words around to rename helper function as getDefaultOpenCLPointeeAddrSpace or getOpenCLDefaultPointeeAddrSpace. Although I am not sure if there are some assumed naming conventions in Clang. Originally, I was following the name of getDefaultCXXMethodAddrSpace.

Sep 21 2021, 3:40 AM · Restricted Project
Anastasia added inline comments to D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.
Sep 21 2021, 3:36 AM · Restricted Project, Restricted Project
Anastasia added inline comments to D109818: [HIPSPV] Convert HIP kernels to SPIR-V kernels.
Sep 21 2021, 2:50 AM · Restricted Project
Anastasia added inline comments to D109874: [OpenCL] Defines helper function for OpenCL default address space.
Sep 21 2021, 2:38 AM · Restricted Project

Sep 10 2021

Anastasia added a comment to D109609: [C++4OpenCL] Add support for multiple address spaced destructors.

The feature is also C++ for OpenCL specific to let the fast path remain when not utilizing the
address spaces, as this new implementation will be slower than the bitfields that C++ currently
uses, but I hope this can also be optimized in the future if it turns out to be very slow.

Sep 10 2021, 12:56 PM · Restricted Project
Anastasia added inline comments to D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.
Sep 10 2021, 6:58 AM · Restricted Project, Restricted Project
Anastasia added inline comments to D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.
Sep 10 2021, 6:51 AM · Restricted Project, Restricted Project
Anastasia accepted D109366: [OpenCL] Tests C++ for OpenCL version macros.

LGTM! Thanks

Sep 10 2021, 6:46 AM · Restricted Project
Anastasia accepted D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

Please, address suggested test simplifications in the final commit if applicable.

Sep 10 2021, 6:44 AM · Restricted Project, Restricted Project
Anastasia added inline comments to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.
Sep 10 2021, 6:41 AM · Restricted Project, Restricted Project
Anastasia committed rGfbe00c6874f1: [OpenCL][Docs] Update OpenCL 3.0 status info. (authored by Anastasia).
[OpenCL][Docs] Update OpenCL 3.0 status info.
Sep 10 2021, 5:07 AM
Anastasia committed rG9685631cbeb8: [OpenCL][Docs] Added ref to libclcxx (authored by Anastasia).
[OpenCL][Docs] Added ref to libclcxx
Sep 10 2021, 4:31 AM
Anastasia closed D109526: [OpenCL][Docs] Added ref to libclcxx.
Sep 10 2021, 4:31 AM · Restricted Project
Anastasia committed rGcff03d5fc487: [OpenCL][Docs] Update OpenCL 3.0 implementation status. (authored by Anastasia).
[OpenCL][Docs] Update OpenCL 3.0 implementation status.
Sep 10 2021, 4:24 AM
Anastasia closed D109320: [OpenCL][Docs] Update OpenCL 3.0 implementation status..
Sep 10 2021, 4:24 AM · Restricted Project
Anastasia closed D109327: [OpenCL][Docs] Release 13 notes.

this is now on the release branch https://github.com/llvm/llvm-project/commit/9723fc15338e83737d0c5f7cbf415e7f1d9d1ec3

Sep 10 2021, 4:15 AM

Sep 9 2021

Anastasia requested review of D109526: [OpenCL][Docs] Added ref to libclcxx.
Sep 9 2021, 9:45 AM · Restricted Project
Anastasia added inline comments to D109366: [OpenCL] Tests C++ for OpenCL version macros.
Sep 9 2021, 5:41 AM · Restricted Project
Anastasia added inline comments to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.
Sep 9 2021, 4:02 AM · Restricted Project, Restricted Project
Anastasia accepted D109492: [OpenCL] Test case for C++ for OpenCL 2021 in OpenCL C header test.

LGTM! Thanks

Sep 9 2021, 3:46 AM · Restricted Project
Anastasia accepted D109424: [OpenCL] Supports atomics in C++ for OpenCL 2021.

LGTM! Thanks!

Sep 9 2021, 3:45 AM · Restricted Project
Anastasia accepted D109370: [OpenCL] Enables .rgba vector extension in C++ for OpenCL 2021.

LGTM! Thanks

Sep 9 2021, 3:42 AM · Restricted Project
Anastasia added inline comments to D109366: [OpenCL] Tests C++ for OpenCL version macros.
Sep 9 2021, 3:41 AM · Restricted Project
Anastasia updated the diff for D109327: [OpenCL][Docs] Release 13 notes.
  • Addressed review comments from @Topotuna
  • Reordered items to group features and fixes
Sep 9 2021, 3:38 AM

Sep 7 2021

Anastasia accepted D109328: [OpenCL] Supports optional writing to 3d images in C++ for OpenCL 2021.

LGTM! Thanks

Sep 7 2021, 2:18 AM · Restricted Project

Sep 6 2021

Anastasia added a comment to D109327: [OpenCL][Docs] Release 13 notes.

Due to the release completion schedule and my planned absences, it is likely that this needs finalizing by the end of the week. Any small changes can still be added later on should you wish to improve something afterwards up until the release branch is frozen. I just want to make sure that we don't miss adding the main content for the release.

Sep 6 2021, 10:58 AM
Anastasia requested review of D109327: [OpenCL][Docs] Release 13 notes.
Sep 6 2021, 8:23 AM
Anastasia added inline comments to D109320: [OpenCL][Docs] Update OpenCL 3.0 implementation status..
Sep 6 2021, 6:18 AM · Restricted Project
Anastasia added a comment to D109320: [OpenCL][Docs] Update OpenCL 3.0 implementation status..

@azabaznov and @airlied the main feedback I am looking for is whether I have missed any important patch and whether you agree with the judgement about the completion status.

Sep 6 2021, 6:00 AM · Restricted Project
Anastasia requested review of D109320: [OpenCL][Docs] Update OpenCL 3.0 implementation status..
Sep 6 2021, 5:55 AM · Restricted Project
Anastasia accepted D109150: [OpenCL] Disallows static kernel functions in C++ for OpenCL.

Cool! Thanks

Sep 6 2021, 5:49 AM · Restricted Project
Anastasia accepted D109307: [OpenCL] Supports optional same image reads and writes in C++ for OpenCL 2021.

LGTM! Thanks

Sep 6 2021, 3:10 AM · Restricted Project
Anastasia accepted D109306: [OpenCL] Supports optional pipe types in C++ for OpenCL 2021.

LGTM! Thanks

Sep 6 2021, 3:08 AM · Restricted Project
Anastasia accepted D109305: [OpenCL] Supports optional program scope global variables in C++ for OpenCL 2021.

LGTM! Thanks

Sep 6 2021, 3:05 AM · Restricted Project
Anastasia added inline comments to D109150: [OpenCL] Disallows static kernel functions in C++ for OpenCL.
Sep 6 2021, 3:02 AM · Restricted Project
Anastasia accepted D109002: [OpenCL] Supports optional image types in C++ for OpenCL 2021.

LGTM! Thanks

Sep 6 2021, 2:55 AM · Restricted Project

Sep 2 2021

Anastasia updated subscribers of D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

CC: @bader @svenvh

Sep 2 2021, 5:41 AM · Restricted Project, Restricted Project
Anastasia added a reviewer for D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info: Anastasia.
Sep 2 2021, 5:40 AM · Restricted Project, Restricted Project
Anastasia added a comment to D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info.

Generally LGTM!

Sep 2 2021, 5:39 AM · Restricted Project, Restricted Project

Sep 1 2021

Anastasia added a comment to D106343: [OpenCL] Support cl_ext_float_atomics.

Hi, svenvh and Anastasia. If you approve the patch, could you please submit it?
I don't have permission to do it.

Sep 1 2021, 12:54 PM · Restricted Project
Anastasia accepted D108360: [clang][NFC] Remove dead code.

LGTM! Thanks!

Sep 1 2021, 11:21 AM · Restricted Project
Anastasia added a comment to D108360: [clang][NFC] Remove dead code.

@Anastasia is this good to go for you or does this need closer attention?

Sep 1 2021, 11:21 AM · Restricted Project
Anastasia accepted D108470: [OpenCL] Fix as_type3 invalid store creation.

LGTM! Thanks

Sep 1 2021, 11:11 AM · Restricted Project
Anastasia accepted D108761: [OpenCL] Remove decls for scalar vloada_half and vstorea_half* fns.

LGTM! Thanks

Sep 1 2021, 11:08 AM · Restricted Project
Anastasia accepted D108461: [OpenCL] Supports optional generic address space sematics in C++ for OpenCL 2021.

LGTM! Thanks

Sep 1 2021, 10:22 AM · Restricted Project
Anastasia added inline comments to D109002: [OpenCL] Supports optional image types in C++ for OpenCL 2021.
Sep 1 2021, 10:20 AM · Restricted Project
Anastasia added inline comments to D109002: [OpenCL] Supports optional image types in C++ for OpenCL 2021.
Sep 1 2021, 2:33 AM · Restricted Project
Anastasia accepted D108989: [OpenCL] Supports optional 64-bit floating point types in C++ for OpenCL 2021.

LGTM! Thanks

Sep 1 2021, 2:30 AM · Restricted Project

Aug 26 2021

Anastasia accepted D108693: [OpenCL] Defines helper function for kernel language compatible OpenCL version.

This is a very nice clean up!

Aug 26 2021, 10:11 AM · Restricted Project
Anastasia accepted D108704: [OpenCL] Define OpenCL 3.0 optional core features in C++ for OpenCL 2021.

LGTM! Thanks

Aug 26 2021, 10:08 AM · Restricted Project
Anastasia added a comment to D107769: [OpenCL] Make generic addrspace optional for -fdeclare-opencl-builtins.

I have done an alternative spin of this patch: instead of introducing RequireDisabledExtension, simply always make the private, global, and local overloads available. This makes tablegen diverge from opencl-c.h though. Perhaps we should also always add make the private, global, and local overloads available in opencl-c.h?

Aug 26 2021, 10:05 AM · Restricted Project

Aug 25 2021

Anastasia updated subscribers of D108392: [OpenCL] Fix parsing of opencl-c.h in CL 3.0 with device-scope atomics enabled.
Aug 25 2021, 2:53 AM · Restricted Project
Anastasia added a comment to D108461: [OpenCL] Supports optional generic address space sematics in C++ for OpenCL 2021.

__opencl_c_generic_address_space should not have been chosen as the first feature to be addressed out of all OpenCL 3.0 optional core features. This is because __opencl_c_device_enqueue has a dependency on this feature. I will review the order in which OpenCL 3.0 optional features should be introduced to C++ for OpenCL 2021 and return to this revision when all dependencies are resolved.

Aug 25 2021, 2:45 AM · Restricted Project
Anastasia accepted D108367: [NFC] computeSPIRKernelABIInfo(): use SPIRABInfo.

Do you think we can test this somehow?

Aug 25 2021, 2:42 AM · Restricted Project
Anastasia requested changes to D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.
Aug 25 2021, 2:41 AM · Restricted Project, Restricted Project
Anastasia added inline comments to D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping.
Aug 25 2021, 2:40 AM · Restricted Project, Restricted Project

Aug 23 2021

Anastasia accepted D107553: [C++4OpenCL] Initialize temporaries in the private address space.

LGTM! Thanks

Aug 23 2021, 2:39 AM · Restricted Project
Anastasia accepted D108449: [clang][NFC] Tighten up code for GetGlobalVarAddressSpace.

LGTM! Thanks

Aug 23 2021, 2:38 AM · Restricted Project
Anastasia added inline comments to D108461: [OpenCL] Supports optional generic address space sematics in C++ for OpenCL 2021.
Aug 23 2021, 2:35 AM · Restricted Project

Aug 19 2021

Anastasia accepted D108379: [OpenCL] Fix version reporting of C++ for OpenCL 2021.

I imagine you will be adding some tests that will check the correctness of diagnostic wording in the subsequent commits?

Aug 19 2021, 8:32 AM · Restricted Project
Anastasia accepted D107539: [OpenCL] opencl-c.h: add __opencl_c_images and __opencl_c_read_write_images.

LGTM! Thanks

Aug 19 2021, 2:14 AM · Restricted Project

Aug 18 2021

Anastasia requested changes to D108113: [C++4OpenCL] Enable -cl-std flag clc++21 as a shorthand for clc++2021.

@svenvh I would like to discuss it further with Sven whether it is a good direction or not?

The underlying motivation for adding those aliases seems to be missing from the description.

Personally, I do not see the point of adding aliases to save two characters (you only save the "20" part of "clc++2021"), while adding potential confusion ("is the language called C++ for OpenCL 2021 or C++ for OpenCL 21, or maybe it has something to do with OpenCL 2.1?"). Also they are being added as deprecated aliases, suggesting they might be removed at some point in the future again?

I'd much rather see one canonical way of specifying the language version, instead of adding multiple aliases to do the same thing. But perhaps there is a good reason that I am not aware of?

Aug 18 2021, 4:26 AM · Restricted Project

Aug 17 2021

Anastasia accepted D107963: [OpenCL] Fix as_type(vec3) invalid store creation.
Aug 17 2021, 5:25 AM · Restricted Project
Anastasia updated subscribers of D108113: [C++4OpenCL] Enable -cl-std flag clc++21 as a shorthand for clc++2021.

@svenvh I would like to discuss it further with Sven whether it is a good direction or not?

Aug 17 2021, 4:59 AM · Restricted Project
Anastasia added a reviewer for D108038: [C++4OpenCL] C++ for OpenCL version 2021 introduced to command line: svenvh.
Aug 17 2021, 4:57 AM · Restricted Project
Anastasia accepted D108038: [C++4OpenCL] C++ for OpenCL version 2021 introduced to command line.

Let's add a reference to RFC in the description: https://lists.llvm.org/pipermail/cfe-dev/2021-August/068593.html

Aug 17 2021, 4:57 AM · Restricted Project
Anastasia added a comment to D108034: [SPIR-V] Add SPIR-V builtin functions and types.

Can you elaborate the overall design flow please? Particularly, it is not clear why we need to duplicate OpenCL types and builtins at source level for SPIR-V... Is there any way to avoid this?

Aug 17 2021, 3:15 AM · Restricted Project