[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

[Pekka Jääskeläinen via Phabricator via cfe-commits]

pekka.jaaskelainen added inline comments.


================
Comment at: docs/UsersManual.rst:2120
+  that can be used across GPU toolchains. The implementation follows `the SPIR
+  specification <https://www.khronos.org/spir>`_. There are two flavors available
+  for 32 and 64 bits.
----------------
Anastasia wrote:
> bader wrote:
> > pekka.jaaskelainen wrote:
> > > Which version of SPIR is generated?
> > For -cl-std=CL1.x (where x is 0, 1 or 2), SPIR version is 1.2.
> > For -cl-std=CL2.0, SPIR version is 2.0.
> Is it worth mentioning this in this doc?
I think so as SPIR V is now there also.


================
Comment at: docs/UsersManual.rst:2130
+
+- x86 is used by some implementations that are x86 compatible
+  (e.g. `POCL <http://portablecl.org/>`_) and currently remains for backwards
----------------
Anastasia wrote:
> pekka.jaaskelainen wrote:
> > This is a bit confusing paragraph, probably due to my confusing explanations of the problems with pocl. Currently pocl tries not to use FASM for preserving logical AS IDs to LLVM IR due to the bunch of problems it constantly produces with seemingly little benefits for common CPUs. My patch related to this considered only the argument info switch. Now pocl only derives the logical iDS from kernel arguments (and all other IDs within the body of the IR function are lost for flat machines).  In my patch, the argument info's address space IDs were made constant and identical to SPIR's as previously they were the target's (which meant losing the AS IDs altogether for flat AS machines).
> > 
> > You seem to document the arg-info md switch later, so this paragraph might be removed or converted to my pocl blurb which mentions the need for further processing for CPUs.
> Yes, it's perhaps a bit confusing indeed. I find the usage of the x86 backend for OpenCL is generally a bit confusing. Also there are a lot of program paths even in Clang that don't play well for OpenCL purposes or are not handled properly and are therefore a source of bugs.
> 
> I was just wondering whether it would be possible to switch to using SPIR as a generic target at some point in the future and "deprecate" the x86 target for OpenCL . Do you think this might work for POCL? At the same time we have upcoming SPIR-V support as a new feature that might reshape things.
> 
> Regarding the address space I just know that it's common to use fake address space map with the x86 backend for some out of tree implementations to add missing memory segments to this target. That's why I added this text here.
> 
> 
We have considered using SPIR internally, but it is likely to bring the same problems as with the FASM as we need to convert to the target bitcode to ensure all target specific IR level optimizations (especially vectorization) is applied properly. Why do you think using the real target when generating from OpenCL C kernels is problematic? 


================
Comment at: docs/UsersManual.rst:2133
+
+- x86 is used by some implementations that are x86 compatible and currently
+  remains for backwards compatibility (with older implementations prior to
----------------
ARM (and others) are treated similarly in pocl: OpenCL C is just yet another frontend language in this picture, like C/C++. I would not "deprecate" that path as of yet as forcing to another intermediate representation (which SPIR basically is, albeit derived from LLVM IR) always loses some information on the way.


https://reviews.llvm.org/D28080