Re: built-in-setjmp.c failure

[Jan Hubicka <jh at suse dot cz>]

> 
> 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