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

[Zhuravlyov, Konstantin via llvm-commits]

Hi Adrian and David,

Is there any other outstanding feedback? Or are the remaining dwarf address space patches good to be committed? I have submitted the one accepted by Adrian.

Thanks,
Konstantin

From: aprantl at apple.com [mailto:aprantl at apple.com]
Sent: Monday, February 20, 2017 12:53 PM
To: David Blaikie <dblaikie at gmail.com>
Cc: Tye, Tony <Tony.Tye at amd.com>; reviews+D29670+public+eb80bff8fcde0c0d at reviews.llvm.org; Zhuravlyov, Konstantin <Konstantin.Zhuravlyov at amd.com>; Arsenault, Matthew <Matthew.Arsenault at amd.com>; frej at sics.se; Purnomo, Budirijanto <Budirijanto.Purnomo at amd.com>; Chan, SiuChi <siuchi.chan at amd.com>; axwalk at gmail.com; Ding, Wei <Wei.Ding2 at amd.com>; llvm-commits at lists.llvm.org; nhaehnle at gmail.com
Subject: Re: [PATCH] D29670: [DebugInfo] Emit address space with DW_AT_address_class attribute for pointer and reference types

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<mailto: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




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