DWARFv5 DW_FORM_implicit_const support in LLVM

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.

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.

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

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

-Jini.