llvm dev - Nov 2019 - 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191105/32ebf5df/attachment.html>

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/20191105/242b1ef7/attachment.html>

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>