OpenCL address space and mangling

[Mon Ping Wang]

HI Michele, 
On Aug 2, 2013, at 2:57 PM, Michele Scandale <michele.scandale at gmail.com> wrote:

> Hello Mon Ping,
> 
> I apologize for the mail length, but I hope to explain as clear as I can the points I think need to be discussed.
> 
>> Sorry of being late to this conversation. It doesn’t look consistent me. Address
>> space numbers are not language constructs.   The language constructs are global
>> and local.  Coming out of clang, I think it is more natural for the AS mangling
>> and the type to match. In C++, clang will generate different names for
>> structures which can be identical and uses those names consistently to mangle
>> the function, e.g.,
>>   %struct.foo = type { i32, i32 }
>>   define void @_Z4testR3foo(%struct.foo* %foo)
>> 
>> I view the address spaces coming out of clang represent how the target represent
>> memory is a logical.  How a particular llvm maps them to physical memory is
>> target dependent.  A backend may map them all the address spaces to the same
>> physical memory or to different ones.  Due to this, I don’t think it make sense
>> to distinguish between the two in clang for a particular target.
> 
> I agree, the fact that opencl address spaces are handled like other address spaces is a technical aspect. To have a common way I don't see a strict limitation in how address spaces are mangled (they can be numbers decided as convention in clang, or defined by targets, or whatever), but still mangling should preserve the differences that are present in the source language.
> 
> I want to remark IMO an important aspect:
> "Pointer types may have an optional address space attribute defining the numbered address space where the pointed-to object resides. The default address space is number zero. The semantics of non-zero address spaces are target-specific." (http://llvm.org/docs/LangRef.html#pointer-type)
> 
> From this description I understand that address spaces in the IR are physical address spaces. Because of this I consider wrong to use this property as is to represent inside the IR logical address space. Doing that would imply that each backend should be aware of language specific mapping: currently this is not the case and IMO it's a bad idea to have this.
> 
> But a derived information from the source language is still useful to perform optimization, both in the IR and later in the backend: the logical distinction of address spaces is still useful and IMO shoul be represented in the IR. Have both logical and physical address spaces information (it's not important to know is "AS1" means global or local, it's enough to know that 1 is differnt from 2) would be useful to have a better alias analysis also for those targets that physically have one unique address space. I consider that this can be solved independently from the mangling problem.
> 
> The answer to both question, I suggested to introduce another map in order to preserve the distinction between address spaces also for those targets that do not have physical distinct address spaces, like X86, and through this solve the problem related to the mangler.
> 
> As previously discussed, this is not the only viable solution, the mapping of logical address spaces to physical address spaces can be delayed till instruction selection: this would allow the frontend to lower this information in a target independent manner demanding a late IR pass the mapping task (this task would be language/target dependent, so basically who builds the pass pipeline must schedule this language dependent task that requires target informations). Still here may be useful to preserve the logical information of address spaces.
> This kind of solution is feasible, but simply it does not seem the way chosen in clang to solve the problem.
> 
> My proposal was the one with the minimal impact on the codebase trying to maintain a desirable flexibility in order to build opencl toolchain compatible with the past.
> 
> Could you explain to me what you are proposing? How the mangler should be fixed? How address spaces are lowered in the IR? This lowering is target dependent or not? The mangling is also target dependent?
> 

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.

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?

Thanks,
  — Mon Ping



> Thanks in advance.
> 
> Best regards,
> -Michele
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits