OpenCL address space and mangling

[Michele Scandale]

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

Regards,

-Michele
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mangling.patch
Type: text/x-patch
Size: 1357 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130723/fc2bb6da/attachment.bin>