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

Tye, Tony via llvm-commits llvm-commits at lists.llvm.org
Sat Feb 18 12:11:38 PST 2017


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




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


More information about the llvm-commits mailing list