This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
Re: built-in-setjmp.c failure
- To: Geoff Keating <geoffk at redhat dot com>, rth at cygnus dot com, gcc at gcc dot gnu dot org
- Subject: Re: built-in-setjmp.c failure
- From: Jan Hubicka <jh at suse dot cz>
- Date: Tue, 12 Jun 2001 16:30:48 +0200
- Cc: Jan Hubicka <jh at suse dot cz>, gcc-regression at gcc dot gnu dot org
- References: <200106120006.RAA04374@geoffk.org>
>
> Hi Jan,
>
> +Fri Jun 8 21:52:51 CEST 2001 Jan Hubicka <jh@suse.cz>
> +
> + * i386.h (CONST_COSTS): set cost of constants representable in
> + immediate fields to 0.
> +
>
> This seems to cause:
>
> native gcc.sum gcc.c-torture/execute/built-in-setjmp.c
>
> Could you look at it?
The problem is caused by sequence:
(insn 23 21 25 (set (reg/f:SI 62)
(label_ref:SI 33)) -1 (nil)
(insn_list:REG_LABEL 33 (expr_list:REG_EQUAL (label_ref:SI 33)
(nil))))
(insn 25 23 28 (set (mem:SI (plus:SI (reg/f:SI 61)
(const_int 4 [0x4])) 0)
(reg/f:SI 62)) -1 (nil)
(nil))
...
(code_label 33 32 160 3 "" "" [1 uses])
The insn 25 is only use of register 62. CSE does constant propagation:
(insn 25 21 28 (set (mem:SI (const:SI (plus:SI (symbol_ref:SI ("buf"))
(const_int 4 [0x4]))) 0)
(label_ref:SI 33)) 45 {*movsi_1} (nil)
(nil))
And the insn 23 is killed afterwards as trivially dead. So far so good.
Problem is that number of uses of code_label is not updated, so it is also killed.
The question is who should update the number?
We do similar change at two places - cse and constant propagation in gcse.
In GCSE thinks are OK, as reg-scan is rerun afterwards, but still I believe
such update belongs to the validate_replace infrastructure.
On the other hand, it seems to be dificult to determine such thinks there, as
replacing one expression by another would mean that we need to traverse both
for label_refs and do nuses counting, that may increase considerably
cost of the whole beast.
Do you have some ideas for the proper fix?
Honza