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

Adrian Prantl via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 16 14:32:42 PST 2017


> On Feb 16, 2017, at 2:22 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Thu, Feb 16, 2017 at 2:10 PM Adrian Prantl via Phabricator <reviews at reviews.llvm.org <mailto:reviews at reviews.llvm.org>> wrote:
> aprantl added inline comments.
> 
> 
> ================
> Comment at: lib/Bitcode/Reader/MetadataLoader.cpp:1117
> +    Optional<unsigned> AddressSpace = None;
> +    if (Record.size() > 12 && Record[12] != ~0U)
> +      AddressSpace = Record[12];
> ----------------
> kzhuravl wrote:
> > dblaikie wrote:
> > > What's the magical ~0U value about?
> > I used it as a sentinel value to represent "None" optional dwarf address space in the bitcode (we always generate and read address space record, if it is ~0U, then we pass None when creating DIDerivedType).
> >
> > Would it be better to not write address space record if it is None?
> >
> > We can also use UINT24_MAX + 1 (we would need to define UINT24_MAX). or ADDRESS_SPACE_MAX?
> I'm pretty sure we prefer bitcode records from the same LLVM revision to always have the same number of elements.
> Typically we use 0 as the default value and omit it in the textual IR.
> What would you think about encoding the address space as n+1, with 0 being the default=None value?
> 
> I was going to say that seems a bit ugly (compared to using max value as the marker) - but then rememered the bitcode format uses variable length encoding, so encoding the max value probably isn't as cheap as zero, I guess?

Thank you for providing a rational explanation for my gut instinct! :-)
> 
> - Dave
>  
> 
> 
> 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/20170216/69621b56/attachment.html>


More information about the llvm-commits mailing list