[cfe-dev] OpenCL address space and mangling

[Mon Ping Wang]

Hi Michele,

Sorry for the delay response.

On Aug 8, 2013, at 1:22 PM, Michele Scandale <michele.scandale at gmail.com> wrote:

> Hello Mon Ping,
> 
> On 08/08/2013 09:26 PM, Mon Ping Wang wrote:
>> IMO, the description only indicates that an address space is completely target dependent.  For the current x86 target, address spaces > 255 are used for a non-standard address for the stack protector while every  other address space overlaps and maps to the same region in memory.  A target can defined it differently or make some address spaces illegal but it is up to the target.
> 
>> When generating code for a particular target, clang need to decide on how to map the global, local, etc.. for a specific target.  Currently, for X86,  it decides to use different address space to distinguish for overloading knowing that in the target, the address spaces will physically overlap.  This keeps the two sides consistent when mangling based on the LLVM IR address space and keeps the overloaded functions to be distinguished for this particular target.  This choice, as you noted, is to make the mapping target dependent.   If a target wants to map everything to the same address space and wants to overloading of their functions because there is no distinction, it can make that choice at this level.
> 
> So why the addrspace map for X86 is still the trivial one IF the assumption in the backend is that whatever number I choose less than 255 is the same as 0? Maybe for X86 defining a non trivial map is a correct fix, but it's not true in general!
> 
> What if an hypothetical backend would enforce that there exists ONLY address space zero? Why I should not be able to produce a correct mangle for opencl overloaded function that refers to different logical address spaces?
> 

Yes, you are right that in general it is not true.  As we both agree, LLVM address spaces are completely target dependent.  The question is why would someone want to produce different overloaded functions when the llvm backend address space only supports one.  It can’t be for code generation since the code will be the same. A backend may want them to all be mangled to the be the same since they would collapse the number of CL builtin functions they would need to support. 

There are cases when clients may want different LLVM IR address spaces and the mangling.  One case is if someone uses the address space for alias analysis.  Another case is that a platform has a set of devices, some with physical address spaces, and wants to keep the mangled name consistent for the platform.  Both of these cases are target dependent on why they want to do so.


>> My objection to the logical map is that by introducing the CL address names to an address space numbering, it looks very target dependent and if the logical address space vs LLVM IR address space doesn’t match, it looks inconsistent.  In that case, I think we should do what we are currently doing.    Instead of a logical map, if we want to preserve the language constructs in a target independent manner, we should use the language construct names in the overloading as that is language dependent and independent of AS numbers which are LLVM IR concepts; which I believe Eli indicated as well.  If we want to preserve compatibility for some target, we can make it target dependent if they want to map use current address space mapping today or use the language mapping.  I don’t know how Eli or the other code owners feel about having that compatibly mode which will be useful for people want to preserve the old behavior.  Opinions?
> 
> The idea of having something target independent seems considered bad in the previous messages. IMO the usage of numbers can be unpleasant, implementation dependent, but I haven't seen a standardized mangling for OpenCL C.
> 
> My point is that *every* target the mangler should produce different names even if the address space translation map is the trivial one.

I’m not convinced on this point. Can you please explain the use case that you want to support again?

> How the address space information is propagated in the IR and the mangling IMO are orthogonal problem: so the inconsistency you underline conceptually cannot exist by definition.
> 
> What I noticed is that the mangler now produces wrong names respect to its purpose (X86 is only the test case).
> 

If we have both a logical map and a llvm address space maps,  I think it is confusing that the mangled name address space differs from the physical llvm map.  It is like having a type name for managing that has no relationship with the type name in the LLVM IR or the language it is coming from.  If we need to support the CL address spaces mangling to be different from the LLVM IR address space, I think it would be better to be target independent and force mangling to be based on the language (global, local, etc..) , which it sounds like you were not opposed of.  As noted above, there are cases where we want them to match.


— Mon Ping




> Thanks for your reply.
> 
> Regards,
> -Michele