[cfe-dev] Fw: [RFC] Add SYCL programming model support.

Anastasia Stulova via cfe-dev cfe-dev at lists.llvm.org
Fri Feb 8 04:52:07 PST 2019




>> Let me check that I understand this question correctly. Are you asking about implementation of pointer classes representing pointers to different address spaces?

> As for address spaces I think you can shortcut by mapping to OpenCL address spaces indeed. Although I don't know why address space qualifiers wouldn't be used directly actually? At some point I would like to enable address spaces without "__" prefix btw to allow porting OpenCL C code to C++. Not sure if it can create issues for SYCL then. But it's worth making this clear now.



One of the goals of SYCL design is to allow developers to compile and run SYCL code even if the compiler toolchain doesn’t support acceleration through OpenCL.

This is somehow very unfortunate because the specification for SYCL is titled "SYCL integrates OpenCL devices with modern C++". That implies that it targets OpenCL explicitly. If there is shift of focus potentially some update is needed to avoid confusions. However, I believe this is still a side goal of SYCL? There are plenty of other parallel languages that don't target OpenCL. What is the benefit of using SYCL if there is no OpenCL available? Anyway, this is probably not the discussion that belongs here, but since we are touching this topic I feel somehow unfortunate that we have to pay the price in the compiler implementation to working around something that doesn't seem to be a primary use case. :(


Unfortunately "OpenCL address spaces" is not C++ standard feature (yet :)), so if we expose them to the user, the program written with these extensions will not be supported by other C++ compiler like GCC or MSVC. Using standard API allows us to utilize all sorts of extensions for API implementation and emulate them with standard C++ if extensions are not available.

So how do you plan to emulate this it in GCC or MSVC and why can't we use the same pure C++ library based approach in Clang?


It is plausible to assume that it should be easier for C++ developers to adopt new functionality through standard C++ concepts like class/function rather than through language extensions.


My personal opinion is that learning library APIs or a set of new keywords is approximately the same especially for those that already mastered the complexity of C++. However, I have to say understanding the extra "magic" behind what appears to be regular C++ classes some developers might find somewhat counter-intuitive.




> However, I think for SYCL address spaces is just one example of much broader picture? What about all other language features that are wrapped into the libraries? For example the code in SemaOverload.cpp of this commit illustrates that you need a tight coupling between compiler and library.

https://github.com/intel/llvm/commit/03354a29868b79a30e6fb2c8311bb409a8cc2346#diff-811283eaa55fa65f65713fdd7ecaf4aa



We switched to using "function attributes" in later commit https://github.com/llvm/llvm-project/commit/120b4b509d758e27c17111eaa0398b4cecf7575a. Basically SYCL runtime marks functions supposed to be offloaded to the target device with special function attribute (similar to OpenCL `kernel` attribute) and compiler doesn't rely on particular library function names.

One the other hand there are other places where similar dependencies exist. For instance, typical SYCL kernel function captures "accessor" parameters, which provides "view" on the data accessed the by the device code. This accessor class contains a pointer this data and it's initialized on the host. To pass C++ class with a pointer to memory from the host to accelerator we need either:

1. system to support some sort of virtual memory, so the target know how to handle host pointers

2. some cooperation between the compiler and runtime on converting host pointers to target pointers



As OpenCL implementation is not guaranteed to support option (1), we implemented option (2) and current implementation relies on SYCL class method names from the standard, but I guess this might be not the best option. I am going to send a separate email to discuss this topic in more details.

Yes, I think an RFC on that is a good idea! We can potentially brainstorm with the rest of Clang developer and find a more salable and elegant solution rather than trying to emulate libraries behavior in the compiler. Besides breaking conventional libraries design approach it incurs the overhead of costly string operations that in some places might have to be performed on every function call or declaration. I am also wondering if you have made any benchmarking of that. Even if it will be gated away from the rest of the code it will still have to be maintained by others if common functionality is required. It can potentially also impact the Clang test suite time as well.

I think it would be good to have a list of those with some information of how they impact the parser.  Hopefully we can reuse attributes or Clang builtin function mechanism for most of those.




>> I need better understand the “OpenCL C++ route” and how it’s aligned with SYCL design philosophy, which tries to enable programing of accelerators via “extension-free” standard C++.

>As for OpenCL we are just enabling C++ functionality to work in OpenCL. That would mean all the library based language features from OpenCL C++ won't be implemented.



By "library based language features" you mean OpenCL specific data types. Right? If so, I think SYCL can re-use OpenCL C++ implementation by outlining "device code" from the single source and then treating it as a OpenCL C++ program.

Yes, it's address spaces and data types mainly. We do plan to port some of new useful C++ libraries  such as for example an array container. I think you should be able to reuse OpenCL native types/contracts for SYCL. It would be good to have a list however to see how we can make best use of available functionality rather than duplicating similar features.



I agree that SPIR-V support must be added not only for SYCL, but for OpenCL C++ too, as it's necessary part of OpenCL C++ compiler toolchain. I think other extensions/APIs might benefit from having native SPIR-V support in LLVM (e.g. OpenMP/Vulkan).

IIRC, the latest discussion ended with a request to build a community around the translator tool. IMHO, we have the community for a long time, but it's not vocal in the LLVM mailing lists and not visible for LLVM community (I can blame myself too :)). I'm aware of multiple projects using this tool to offload computation to OpenCL accelerators and I'll try to provide the evidence in dedicated mailing thread.

Cool, perhaps it's time to revisit this! I would suggest another RFC!


>> We re-used the OpenCL C++ compiler component here to emit LLVM IR for the “LLVM to SPIR-V” translator. For instance, this pass adjusts accelerator specific data types to the format recognized by the translator [2]. I’m open to the suggestions how to improve the format, so we don’t need “adjusting passes”.

>Just to be more specific I guess you mean the OpenCL C++ prototype compiler here (which is quite different from the implementation in mainline Clang)? Can you explain what kind of adjustments you are trying to make and why the approach from OpenCL C wouldn't apply in your case?



Sure. OpenCL C approach for built-in functions is "Itanuim C++ ABI mangled names in global name space". This doesn't work for OpenCL C++/SYCL as these built-ins collide with user functions. We re-use existing prototype to speed-up SYCL development, but according to my understanding it might violate some LLVM guidelines for extending LLVM IR.

Was that not the same for OpenCL C? All BIFs could be re-declared in the user code. The same applies to C/C++ standard libraries. Perhaps, I am not yet clear what problem you are trying to solve with this. I think it's something SPIR-V related? Just as a side note, LLVM only has one intermediate format that is its IR. Any design should take this into account. The implementation of any fronted feature should work such that generic IR is generated. It's responsibility of the consumer to lower this down to the required format.




>> Anyway https://reviews.llvm.org/D57768 is not related to these topics and it’s aligned with existing CUDA/OpenMP functionality.

>As I wrote, these comments are not to the review but they are conceptually important aspects that the community should align on. It might be good to have a concrete plan before starting to work on something?



I'll write a design document to provide more details on how things are done.

Sure I think this is really great way moving forward! I would specifically be interested in where and how OpenCL implementation can be re-used in SYCL to make sure we can work together towards as much common infrastructure as possible. As suggested before, you might want to cover other related areas like CUDA/OpenMP (if any common functionality exist on a single source concept side) that can be assessed by other communities.

Thanks for clarifications btw! They helped a lot!

Anastasia


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190208/d2ae6d3c/attachment.html>


More information about the cfe-dev mailing list