[llvm-dev] DWARFv5 DW_FORM_implicit_const support in LLVM

[Jini Susan George via llvm-dev]

Thank you very much, David and Paul, for your inputs.

-Jini.

On Tue, Nov 5, 2019 at 11:39 PM Robinson, Paul <paul.robinson at sony.com>
wrote:

> If you’re really interested, I’d say the first step would be to do some
> analysis on existing .debug_info sections and see if you can demonstrate a
> size win.  I should think some would be easy to show:  DW_AT_byte_size on
> DW_TAG_pointer_type would be the same quite a lot (always, for most but not
> all targets), for example.  I’d think that DW_AT_decl_file would be a
> candidate only for file#1.  But these are just intuitive guesses; data is
> what you want.  The question then is, how much extra complexity does it add
> to the DIE management.
>
> --paulr
>
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *David
> Blaikie via llvm-dev
> *Sent:* Tuesday, November 5, 2019 11:24 AM
> *To:* Jini Susan George <jini.susan.george at gmail.com>
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] DWARFv5 DW_FORM_implicit_const support in LLVM
>
>
>
> Nah, doesn't look like LLVM generates implicit_const for any compilation
> output (the output support is only used in unit tests at the moment/in the
> patch you mentioned - probably shouldn't've bothered with that (the dumping
> support is separate & seems fine to have in-tree))
>
> LLVM uses FORM_flag_present for cases where adding the attribute at all is
> only done when the 'true' value is needed (eg: we don't put
> "DW_AT_declaration false" on non-declaration, the attribute isn't used on
> non-declarations at all). Arguably, LLVM could avoid using flag_present
> when a DIE might otherwise share an abbreviation eg: DW_AT_artificial is
> done as flag_present, but that means an artificial and non-artificial
> DW_TAG_subprogram use entirely different abbreviations.
>
> I think it'd be hard to justify using implicit_const in most cases -
> because the value changes between different uses & that would then need
> different abbreviations which would end up more expensive (more bytes) than
> if the alternative inline-value forms had been used.
>
> But I guess if someone comes up with a heuristic about when to use
> implicit_const & data to support it being an improvement in DWARF size, I'm
> not completely opposed to the idea.
>
>
>
> On Mon, Nov 4, 2019 at 11:54 PM Jini Susan George via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello folks,
>
>
>
> I was interested in the support we have for the attribute form
> DW_FORM_implicit_const (DWARFv5 feature) in clang/LLVM. And I had some
> doubts wrt this. I noticed that support for this was put in here in 2017:
>
>
>
>
> https://rev.ng/gitlab/revng-bar-2019/llvm/commit/d9df13befcbc702e239b650dd1f55778d72b8571
>
>
>
> From what I could make out, the support for generating
> DW_FORM_implicit_const is there, but I could not make out the DWARF
> attributes for which this form is being generated currently. Are there any
> attributes for which this form is generated currently ?
>
>
>
> Gcc typically generates this form for a bunch of attributes like:
> DW_AT_decl_file, DW_AT_decl_column, DW_AT_accessibility, DW_AT_defaulted,
> DW_AT_byte_size, etc
>
>
>
> Any pointers are deeply appreciated.
>
>
>
> Thanks,
>
> Jini.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191106/7f1b16c1/attachment.html>