[PATCH] D26157: [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD

Pekka Jääskeläinen via cfe-commits cfe-commits at lists.llvm.org
Wed Nov 2 04:45:24 PDT 2016


pekka.jaaskelainen added a comment.

In https://reviews.llvm.org/D26157#585688, @bader wrote:

> @pekka.jaaskelainen, I have related question: what is the problem with retaining OpenCL address space information in LLVM IR?
>  My understanding is that target CodeGen can ignore this information for the machines with 'flat' address space model.
>  On the other hand I would expect this information be useful for the Optimizer to resolve pointer aliasing.
>  Does it make any sense to keep OpenCL address space information in LLVM IR generated for the machines with 'flat' address space (e.g. CPU)?


Is there nowadays such a thing as "standard OpenCL logical AS IDs" which could be retained down to code gen? I must say I haven't checked the current situation here. It used to be that the logical ids are assumed to be converted to the target ones already in Clang and I'm afraid changing this requires a major rework.

pocl has used the fake-address-space ids until now for exactly this -- retaining the logical AS info in the IR which can be exploited for disjoint address space AA, but is also required for handling the different AS kernel arguments as local arguments must be treated differently memory allocation wise.

However, as all backends are not expected to support mapping the fake address spaces to their internal ones (in single AS it's trivial to simply ignore the AS ids, but for multi-AS machines there has to be explicit mapping) we have had an IR pass that converts the address spaces to the target's before code gen. This pass we call TargetAddressSpaces has grown way too complex and is a major source of bugs all the time.

Also, another source of bugs is the fact that many passes simply ignore address spaces as they have been developed for single AS machines and only tested on them. This leads to bugs where the AS ID info is silently dropped (converted to 0) which makes them hard to catch.  If the pointer creation APIs of LLVM were forced to include the AS ID in the construction, it might yield out majority of these issues -- as long as the coders respect the fact that there can be multiple ASs and not simply use 0 there all the time.

Also, some optimizations such as vectorization might get confused in case it sees non-0 address spaces for CPU targets (e.g. there might not be vectorized intrinsics available for non-0 ASs).

Etc. Thus, due to the limited time our group has available for hunting the bugs that stem from this, I decided it might be best to avoid the use of the "logical IDs" inside IR for now and think about how to implement the disjoint AA without them later on.


Repository:
  rL LLVM

https://reviews.llvm.org/D26157





More information about the cfe-commits mailing list