On Jul 24, 2013, at 7:49 AM, Michele Scandale <michele.scand...@gmail.com> 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. This discussion probably should be moved to the cfe-dev mailing list. I think that its better for Clang to have one consistent way of mangling address spaces regardless of language. I’ve been thinking about this more and another problem I have with not using the Target address space map for mangling is that when you have this: void __attribute__((__overloadable__)) foo(global int *x) You get this: define void @_Z3fooPU10AS16776960b(i8* %x) The address space on the argument is gone (or zero), but yet you have it in the mangled name. So its not consistent. I can agree that its right to mangle the names differently from the language perspective, but what you mangle them to is really target specific. If you want to remove this notion from Clang, then maybe all target specific address space maps should go away and a default one for all is used. Then each LLVM backend can interpret it as they wish. It would be great if some Code owners could weigh in here. -Tanya P.S. Please respond to this email address going forward as I will not be using my apple email anymore.
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
