diff mbox

[1/2] Reducing the overhead of dwarf2 location trracking

Message ID g4d3m7vvol.fsf@linaro.org
State Accepted
Headers show

Commit Message

Richard Sandiford March 4, 2011, 1:53 p.m. UTC
A typo in dwarf2out.c:compare_loc_operands means that we fail to
detect equivalent addresses in location lists.  On this ARM testcase:

    https://bugs.launchpad.net/gcc-linaro/+bug/714921/+attachment/1837418/+files/gcc-oom.i

the patch below reduces the number of lines of assembly from
39,230,550 to 1,266,183 when compiling with -O2 -g.  (On my box,
the original code triggers an OOM in the assembler, so I can't measure
the difference in object sizes.)

Normally I'd install this as obvious, but I'm not sure whether
it qualifies for stage 4.  I hope it does though.  Not being able
to build this file (due to the assembler OOM) is a regression from 4.4.

Bootstrapped & regression-tested on x86_64-linux-gnu.  OK for 4.6?

Richard


gcc/
	* dwarf2out.c (compare_loc_operands): Fix address handling.

Comments

Richard Sandiford March 4, 2011, 2:19 p.m. UTC | #1
Jakub Jelinek <jakub@redhat.com> writes:
> On Fri, Mar 04, 2011 at 01:53:30PM +0000, Richard Sandiford wrote:
>> A typo in dwarf2out.c:compare_loc_operands means that we fail to
>> detect equivalent addresses in location lists.  On this ARM testcase:
>> 
>>     https://bugs.launchpad.net/gcc-linaro/+bug/714921/+attachment/1837418/+files/gcc-oom.i
>> 
>> the patch below reduces the number of lines of assembly from
>> 39,230,550 to 1,266,183 when compiling with -O2 -g.  (On my box,
>> the original code triggers an OOM in the assembler, so I can't measure
>> the difference in object sizes.)
>> 
>> Normally I'd install this as obvious, but I'm not sure whether
>> it qualifies for stage 4.  I hope it does though.  Not being able
>> to build this file (due to the assembler OOM) is a regression from 4.4.
>> 
>> Bootstrapped & regression-tested on x86_64-linux-gnu.  OK for 4.6?
>
> This is ok for 4.6 from RM POV, and as you say, it is obvious
> and it didn't crash just because DW_OP_addr and DW_OP_const[48]u with dtprel
> is created with new_loc_descr (..., ..., 0); and doesn't do anything with
> the second operand, so valx2->v.val_addr will always be NULL and rtx_equal_p
> then always returns false if valx1->v.val_addr is non-NULL.

Thanks, now applied.

Richard
diff mbox

Patch

Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c	2011-03-04 13:08:38.000000000 +0000
+++ gcc/dwarf2out.c	2011-03-04 13:15:28.000000000 +0000
@@ -23178,7 +23178,7 @@  compare_loc_operands (dw_loc_descr_ref x
 	     && valx2->v.val_int == valy2->v.val_int;
     case DW_OP_addr:
     hash_addr:
-      return rtx_equal_p (valx1->v.val_addr, valx2->v.val_addr);
+      return rtx_equal_p (valx1->v.val_addr, valy1->v.val_addr);
     case DW_OP_GNU_implicit_pointer:
       return valx1->val_class == dw_val_class_die_ref
 	     && valx1->val_class == valy1->val_class