This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug debug/67293] New: Very large DW_AT_const_value produced


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67293

            Bug ID: 67293
           Summary: Very large DW_AT_const_value produced
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Keywords: memory-hog, missed-optimization
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

There seems to be no limit on the size of DW_AT_const_value attributes we
generate:

static const int a[1000000] = { 1, [999999] = 1 };
int main() {}

with -O0 -g we produce

 <1><6b>: Abbrev Number: 7 (DW_TAG_variable)
    <6c>   DW_AT_name        : a
    <6e>   DW_AT_decl_file   : 1
    <6f>   DW_AT_decl_line   : 1
    <70>   DW_AT_type        : <0x7e>
    <74>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)

while with -O -g we end up with

 <1><6b>: Abbrev Number: 7 (DW_TAG_variable)
    <6c>   DW_AT_name        : a
    <6e>   DW_AT_decl_file   : 1
    <6f>   DW_AT_decl_line   : 1
    <70>   DW_AT_type        : <0x3d0978>
    <74>   DW_AT_const_value : 4000000 byte block: 1 0 0 0 0 0 0 0 0 0 0 0 ....
....

I think that's hardly useful nor very friendly to consumers.

We also fail to take the opportunity to represent the not optimized out
constant value in the DW_AT_const_value form if it is shorter:

static const int a = 1;
int main() {}

produces

 <1><51>: Abbrev Number: 4 (DW_TAG_variable)
    <52>   DW_AT_name        : a
    <54>   DW_AT_decl_file   : 1
    <55>   DW_AT_decl_line   : 1
    <56>   DW_AT_type        : <0x5b>
    <5a>   DW_AT_const_value : 1
 <1><5b>: Abbrev Number: 5 (DW_TAG_const_type)

when optimized out (1 byte for the const value), compared to

 <1><51>: Abbrev Number: 4 (DW_TAG_variable)
    <52>   DW_AT_name        : a
    <54>   DW_AT_decl_file   : 1
    <55>   DW_AT_decl_line   : 1
    <56>   DW_AT_type        : <0x64>
    <5a>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0  (DW_OP_addr: 0)
 <1><64>: Abbrev Number: 5 (DW_TAG_const_type)

when not optimized out (10 bytes on 64bit archs, 6 bytes on 32bit archs).

I am arriving here because with early LTO debug I'd like to output more
DW_AT_const_value early (before we know whether the decl will go away).

I think the size optimization is "obvious" (maybe to some extend even factor
in relocation cost, thus allow bigger than 10 or 6 byte constants, like
arbitrary non-aggregate constants), a limit on the maximum size should very
likely be controlled by a --param.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]