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?
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. 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).
Thanks for your reply. Regards, -Michele _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
