Up.
On 07/24/2013 04:49 PM, Michele Scandale wrote:
On 07/23/2013 11:36 PM, Tanya Lattner wrote:
However, I actually should have looked at this closer as it actually doesn't map
to what I want it to. I want it to be the following:
1, // opencl_global
3, // opencl_local
2, // opencl_constant
and when there is no address space then it maps to nothing.
So, I don't think your patch is going to work unless the order is changed in the
enum. Because this is not clearly defined in the spec and is implementation
specific and TARGET specific.. then changing that enum is probably not going to
be the right approach either.
I see the point but still we need to preserve the source language difference
with the mangling.
So, I'm going back to my original statement to keep it to be Target specific.
For your library, are these functions actually implemented differently? Wouldn't
they be exactly the same when there is no address space? In our implementation
we have an address space map defined for X86 and then the names get mangled
"correctly" for all targets. But, all the functionality is the same since the
address spaces don't impact codegen for X86.
I'd argue that the fact that address spaces do not impact codegen for X86 is
merely incidental: the issue goes beyond X86 and impacts all targets --
including future ones.
By choosing to use a fake address space map (instead of the one fitting the
target description), we introduce in the IR a potential for breaking future
implementations, even though the current X86 target is not affected. Moreover,
by introducing the fake address map we would violate the semantics of the LLVM
IR addrspace modifier.
Even binary compatibility with libraries already distributed can be easily
achieved.
This patch (see attachment) aims at preserving the mangling that were generated
by using the target address space map for those targets that override it, while
introducing in the mangling the distinction of opencl/cuda address spaces for
those targets that do not have a non trivial target address space map.
By the way, looking beyond the scope of the current issue of mangling, it would
be IMO interesting to start a public discussion on the mailing list about a way
to represent logical address space information different from target-specific
address space (the case for OpenCL and CUDA) in order to allow the
implementation of custom language specific analysis and/or optimization.
As a temporary solution, if one needed the logical address space information in
the IR too for specific purpose (like OpenCL specific optimization), can still
override the address space map of the target.
Thanks again.
Regards,
-Michele
_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
