[llvm-dev] DWARFv5 DW_FORM_implicit_const support in LLVM

[Robinson, Paul via llvm-dev]

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<mailto: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<mailto: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/20191105/46d79403/attachment.html>