This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC/A: Stop cselib.c recording sets of the frame pointer
- From: Richard Sandiford <richard dot sandiford at linaro dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 22 Nov 2017 21:21:59 +0000
- Subject: Re: RFC/A: Stop cselib.c recording sets of the frame pointer
- Authentication-results: sourceware.org; auth=none
- References: <87y3myp5ot.fsf@linaro.org> <20171122175422.GY14653@tucnak>
Jakub Jelinek <jakub@redhat.com> writes:
> On Wed, Nov 22, 2017 at 05:46:26PM +0000, Richard Sandiford wrote:
>> 2017-11-22 Richard Sandiford <richard.sandiford@linaro.org>
>>
>> gcc/
>> * cselib.c (expand_loc, cselib_expand_value_rtx_1): Change
>> justification for checking for the stack and hard frame pointers.
>> Check them by pointer rather than register number.
>> (cselib_record_set): Do nothing for sets of the frame pointer.
>
> Have you checked what effects this has on debug info (both without and with
> frame pointer), say on cc1plus? var-tracking.c uses cselib heavily and such
> changes could break it substantially.
OK, I tried that, i.e. using stage2 with and without the patch to build
stage3 with the patch (just so that cselib.c itself was the same both times),
first with the default options and then with "-O2 -g -fno-omit-frame-pointer".
With -fno-omit-frame-pointer the stage3 .o files were identical with the
before and after stage2s. With default options there was one change to
stage3 reload.o. The code was the same but the location list for "cn"
on reload.c:4591 changed like this:
@@ -127597,7 +127597,7 @@
0002bc28 <End of list>
0002bc38 00000000000102fe 000000000001030a (DW_OP_reg0 (rax))
0002bc4b 0000000000010e45 0000000000010e4d (DW_OP_reg0 (rax))
- 0002bc5e 0000000000010e4d 0000000000010e58 (DW_OP_breg1 (rdx): 45; DW_OP_stack_value)
+ 0002bc5e 0000000000010e4d 0000000000010e58 (DW_OP_breg0 (rax): 38; DW_OP_stack_value)
0002bc73 <End of list>
0002bc83 00000000000102e9 00000000000102fe (DW_OP_reg6 (rbp))
0002bc96 0000000000010e6b 0000000000010e78 (DW_OP_reg6 (rbp))
@@ -127606,7 +127606,7 @@
0002bccc 0000000000010e6b 0000000000010e72 (DW_OP_reg0 (rax))
0002bcdf <End of list>
0002bcef 0000000000010e4a 0000000000010e4d (DW_OP_reg0 (rax))
- 0002bd02 0000000000010e4d 0000000000010e58 (DW_OP_breg1 (rdx): 45; DW_OP_stack_value)
+ 0002bd02 0000000000010e4d 0000000000010e58 (DW_OP_breg0 (rax): 38; DW_OP_stack_value)
0002bd17 <End of list>
0002bd27 0000000000010e4a 0000000000010e61 (DW_OP_reg15 (r15))
0002bd3a <End of list>
The code in both cases is:
10e4a: 83 e8 26 sub $0x26,%eax
10e4d: 4c 89 ff mov %r15,%rdi
10e50: 48 98 cltq
10e52: ff 14 c5 00 00 00 00 callq *0x0(,%rax,8)
10e55: R_X86_64_32S constraint_satisfied_p_array
where the new location correctly accounts for the change in eax.
I'm not sure why the old location was different though.
I realise that sounds too good to be true, so I repeated it just to
make sure.
Thanks,
Richard