[PATCH] D29670: [DebugInfo] Emit address space with DW_AT_address_class attribute for pointer and reference types

[Adrian Prantl via llvm-commits]

I also think calling it Dwarf.* is fine. Our *current* model for DIExpression and all IR debug info metadata is to use "uncompressed" DWARF (or something very close to it) as the intermediate format in the compiler. If the Dwarf semantics for a particular entity are expressive enough to allow translation into DWARF and CodeView, we're going with it rather than introducing our own serialization (with potentially less well-defined semantics, etc...).

-- adrian

> On Feb 18, 2017, at 12:32 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> Fair point - yeah, not sure. (in any case - given this goes in DWARF expressions, etc, DwarfAddressSpace seems reasonable)
> 
> On Sat, Feb 18, 2017 at 12:11 PM Tye, Tony <Tony.Tye at amd.com <mailto:Tony.Tye at amd.com>> wrote:
> The tricky thing is that the location expressions are being built before the backend. So any deference or XDREF needs to be created before the backend. For the XDEREF the target needs to say when it is required. If all this were to be sunk down then would the notion of these location expressions also be abstracted so they are not DWARF expressions?
> 
>> On Feb 18, 2017, at 2:47 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> 
>> I'd probably name it DwarfAddressSpace, if that's the notion. (if another client (CodeView debug info) needs a different address space scheme - such that we need multiple mappings, at that point I'd probably be inclined to sink it down - use the llvm address space in the IR and map to format specific address spaces in the backend)
>> 
>> On Sat, Feb 18, 2017 at 11:29 AM Konstantin Zhuravlyov via Phabricator <reviews at reviews.llvm.org <mailto:reviews at reviews.llvm.org>> wrote:
>> kzhuravl added inline comments.
>> 
>> 
>> ================
>> Comment at: include/llvm/IR/DebugInfoMetadata.h:715
>> +  /// pointer or reference type respectively.
>> +  Optional<unsigned> AddressSpace;
>> +
>> ----------------
>> Since this is a mapped address space and not LLVM address space (in our case it is Target-specific DWARF Address Space), the name should reflect that.
>> 
>> We were thinking of prefixing it with "DI", but not sure what the policy is here. Seems like types are prefixed with "DI".
>> 
>> Would there be any objections if we rename it to DIAddressSpace?
>> 
>> 
>> https://reviews.llvm.org/D29670 <https://reviews.llvm.org/D29670>
>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170220/e7811271/attachment.html>