HI Michele,
On Aug 2, 2013, at 2:57 PM, Michele Scandale <[email protected]> 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
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
