Ping.

Re-base patch and fix lit test failures.

In D89909#2448443, @Anastasia wrote:

If you prefer to continue this route then you should just document your dialect sematic somewhere publicly accessible and avoid aliasing to OpenCL, or target address spaces. So it would become a proper language dialect implementation.

@erichkeane, @mdtoguchi, we should upstream support for SYCL-2020 version in addition to SYCL-2017.

In D91935#2442723, @tstellar wrote:

In my opinion , it would be better to to build against an installed version of the library, rather than fetching the git source. But I don't have any objections to this specific patch, because it is updating something that is already in tree.

In D89909#2439837, @Anastasia wrote:

In D89909#2423750, @bader wrote:

It was mentioned that the changes in the type system with address spaces is undesirable for SYCL because you indend to parse existing C++ code as-is. This contradicts the intended semantic of address spaces where the whole point of it is to modify the standard types and therefore a compilation of C++ with the standard semantic is only guaranteed when the attribute is not used at all.

Right, but I don't think it's related to the address space attributes. It was mentioned in the context of re-using OpenCL *mode* for SYCL device compilation, which modifies types which does use address space attribute explicitly. "Existing C++ code" doesn't use address space attributes and our solution does differentiate explicitly annotated type. The difference with OpenCL mode is that SYCL doesn't change types by modifying "default" address space attribute and allows conversion from/to "default" address space. As I mentioned in RFC, according to my understanding this patch doesn't contradict Embedded C requirements regarding address space attribute usage. I think the spec allows an implementation to define conversion rules between address spaces and doesn't imply type change based on the declaration scope - it's OpenCL specific behavior.

Ok, if you plan to follow the Embedded C semantic (which your current patch confirms) then you should just reuse the existing target address spaces and extend the implementation with the ability to specify the relation among address spaces. The patch that you have mentioned earlier https://reviews.llvm.org/D62574 is providing this logic already and it looks good aside from testing. I would suggest to discuss with @ebevhan the timeline for committing it as the testing could be done using SYCL implementation. Alternatively, you could consider reusing the relevant parts of the patch if @ebevhan has no objections to that.

@tstellar, are you okay with the change?
Please, let us know if you have any additional questions.

Fix clang-format issues.

Move CodeGen crash fix to a separate review request: https://reviews.llvm.org/D92782

Apply code review comment from @rjmccall

I didn't sense any agreement or any sort of a conclusion on the RFC. Moreover, I didn't feel at all that the existing address space attribute was a good fit. I was suggesting to add a different attribute that isn't an address space attribute from Embedded C. I don't understand what you gain from the existing address space attribute at the moment.

In D91935#2414448, @tstellar wrote:

Can you explain more about what llorg is and why this change is needed?

@etyurin, let me know when it's ready for commit.

In D91935#2411726, @ekovanov wrote:

Hi @etyurin ,
I do not have commit access - could you please land it?

I also suggest using CMake's ExternalProject_Add command to checkout sources instead of running a set of execute_process commands.

Did anyone conclude there that the language address spaces should be added for SYCL? I can't see any of this. In fact I don't even think there was any conclusion on the RFC. You should first make your design clear and agreed before going ahead with the implementation. I personally still think that address space AST attribute is not the right path for SYCL. And I haven't seen any evidence that it is the best solution to what you are trying to achieve.

Upload full patch after removing sycl_constant address space attribute support.

Remove support for sycl_constant address space attribute.

In D89909#2353931, @Anastasia wrote:

In the RFC it has been discussed to either use target address spaces or perhaps to introduce a new attribute to reflect a semantic needed for SYCL, but it seems to me in this change you are building on top of the existing language address space attribute with new entries for SYCL.

http://lists.llvm.org/pipermail/cfe-dev/2020-August/066632.html

Alternative approach with SYCL specific semantic attributes - https://reviews.llvm.org/D89909.

Applied Ronan's suggestion.

You might need add [OpenCL] tag to the commit message.

Thanks!

I'm okay with this change in general. One note though.

In D80932#2085848, @Anastasia wrote:

In D80932#2083185, @bader wrote:

In D80932#2080631, @Anastasia wrote:

@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.

Thanks! This is good but it is only an implementation of the design. Deducing the design from an implementation is time-consuming and not sure it is even feasible. I don't want to waste our time to provide you detailed feedback based on my interpretation of your design and invalid assumptions. I don't want to bind you to any particular format and we don't have any strict requirement for this in LLVM either, but I would encourage you to take a look at some of RFC threads sent to cfe-dev that explain new design concepts. Perhaps, they can help you to understand what information can be provided as a starting point to new design discussions.

Particularly I would suggest covering these two points:

• SYCL specifies address spaces as classes and it is not very obvious how did you come from libraries classes to modifications in Clang? I believe there are a number of design choices that you could make. One might think that you can just implement address space classes using existing Clang functionality. But if it is not sufficient it is important to understand what modifications are required and why.

• Other aspects that are important to highlight whether your design has any limitations. For example, I don't quite understand your need for SPIR*SYCLDeviceTargetInfo. Is there anything in your design that limits compilation to one particular target?

Overall, I see that there are a lot of changes in CodeGen that are related to the language semantic. I believe that CodeGen is supposed to be dialing primarily with target-specific logic and I don't know if you should change them to query target specific details instead. Also most of your CodeGen changes are not related to OpenCL so I would make sure to loop @rjmccall in this thread.

In D81641#2097433, @Fznamznon wrote:

Seems that test/OpenMP/nvptx_target_codegen.cpp is completely not formatted. If I apply suggestion from pre-merge checks, this will look like a big unrelated to this patch change and it will contradict with the whole file style.

In D80932#2080631, @Anastasia wrote:

@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.

In D80932#2074792, @Anastasia wrote:

I think my biggest problem is that I don't understand how you can just run C++ libraries on OpenCL devices. If we were able to compile plain C++ for OpenCL devices would we not just do it? But OpenCL devices have certain constraints. Also aren't libraries typically customized for performance depending on the range of HW they are being run on? I see the modifications are inevitable.

In D80932#2068863, @Anastasia wrote:

Fix formatting in clang/test/Sema/address_spaces.c

• Added C test case with address_space attribute.
• Move isAddressSpaceOverlapping from PointerType to QualType.
• Move C++ test case to clang/test/SemaCXX

Thanks for the review.
I've enabled the diagnostics for all the modes.
I also applied the refactoring suggested by @rjmccall. Hopefully I understand it correctly.

Enable diagnostics for non-OpenCL modes and applied refactoring proposed by John.

In D77220#1954909, @erichkeane wrote:

@bader : Is this what you meant? Feel free to add any reviewers you want for this. Note it is still dependent on D71016.

LGTM. Thanks!

LGTM. Thanks!

In D72857#1895649, @bader wrote:

In D72857#1895625, @thakis wrote:

This landed here: https://github.com/llvm/llvm-project/commit/bd97704eaaaab5a95ecb048ce343c1a4be5d94e5

It broke tests on mac: http://45.33.8.238/mac/9011/step_7.txt

Please take a look, and if it takes a while please revert while you investigate.

@thakis, thank for letting me know. I've reverted it at 740ed617f7d4d16e7883636c5eff994f8be7eba4. Sorry for inconvenience.

In D72857#1895625, @thakis wrote:

This landed here: https://github.com/llvm/llvm-project/commit/bd97704eaaaab5a95ecb048ce343c1a4be5d94e5

It broke tests on mac: http://45.33.8.238/mac/9011/step_7.txt

Please take a look, and if it takes a while please revert while you investigate.

Any other comments?

Rebase to ToT and address comments from Ronan.

Address comments from Victor and Alexey.

Ping.

Applied review commits from Alexey.

Applied code review comments.

Ignore -sycl-std if it used in non-SYCL mode.

Applied Alexey's comments.

Applied suggestions from Alexey and Ruyman and rebased on ToT.