OpenCL address space and mangling

[Tanya Lattner]

On Jul 23, 2013, at 3:21 AM, Michele Scandale <michele.scandale at gmail.com> wrote:

> Hi Tanya,
> 
>> I understand what you are saying, but I'm arguing that the Target needs to define the address space map in order for this to mean anything at all. If its not defined, then what does global or local mean? What happens when this is lowered to LLVM IR?
> 
>> Why not define an address space map for X86?
>> 
> 
> The trivial address map is the correct one for X86, since it does not have
> separate address spaces.
> The problem is that at the language level, address space specifiers carry
> additional information over that related to the memory allocation. In
> particular, the specifiers cause function prototypes to refer to different
> functions even if they differ only for an address space specifier.
> 
> Going back to my earlier example, the following function declaration
> 
> __attribute__((overloadable)) void foo(__global float *a)
> 
> and
> 
> __attribute__((overloadable)) void foo(__local float *a)
> 
> would be mapped to the same mangled name because of the mapping of local and
> global address space to the single physical address space provided by X86, so
> the high level information is lost.
> 
> Thus, the issue is not that the address spaces are mapped incorrectly, but
> rather that the mangling should not be based on the map, but on the original
> address space specifiers.
> 
> *Ignoring the semantics of the IR addrspace modifier, which is TARGET-specific*,
> we could indeed define a custom mapping for X86 which artificially preserved
> multiple address spaces, and the above example would work correctly. But  the
> proposed X86 mapping would actually be a target-independent but language
> dependent mapping useful at the higher levels of the compiler (before code
> generation).
> 
> The fact that using untranslated address spaces is aesthetically unpleasant can
> be easily solved with a specialization of the mangling, one for OpenC and one
> for CUDA. This solution would be semantically correct and would maintain the
> mangling meaningful (see attachment).
> 

Ok, this approach will work for me. However, I would prefer to not have CL prefix and keep it as AS#.

Thanks,
Tanya

> Regards,
> 
> -Michele
> <mangling.patch>