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

[David Blaikie via llvm-commits]

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> 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> 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> 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/b1077228/attachment.html>