[PATCH] Remove redundant constant stores in RTL DSE (PR middle-end/31150)

Jakub Jelinek jakub@redhat.com
Wed Dec 17 09:48:00 GMT 2008


On Tue, Dec 16, 2008 at 06:06:26PM -0800, Adam Nemet wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> > we see:
> > (insn 16 15 17 2 t.c:7 (set (reg:DF 64)
> >         (mem/u/c/i:DF (symbol_ref/u:DI ("*.LC1") [flags 0x2]) [3 S8 A64])) 103 {*movdf_integer_rex64} (expr_list:REG_EQUAL (const_double:DF 0.0 [0x0.0p+0])
> >         (nil)))
> >
> > (insn 17 16 18 2 t.c:7 (set (mem/s/c:DF (plus:DI (reg/f:DI 20 frame)
> >                 (const_int -136 [0xffffffffffffff78])) [3 a.b+0 S8 A64])
> >         (reg:DF 64)) 103 {*movdf_integer_rex64} (expr_list:REG_DEAD (reg:DF 64)
> >         (nil)))
> > but reg:DF 64 isn't constant, nor we have a REG_EQUAL note on the store insn
> > (as e.g. fwprop adds for integer constants on targets like ppc where
> > RHS of store must be a register), and even cselib_expand_value_rtx
> > doesn't return anything but the passed pseudo.
> 
> Can't you do a cselib_lookup and look through setting_insn of locs for a
> REG_EQUAL/REG_EQUIV?

dse.c calls cselib_init (false), so cselib_record_memory is false.
This means MEMs aren't tracked and so for REG_VALUES (64) above
in l->elt->locs there is just one entry with the REG itself.
If cselib_init (true) is called instead, there will be also
entry with that MEM/c and thus setting_insn pointing to insn 16 above,
so cselib_expand_value_rtx (particularly expand_loc) could look at it
and return REG_EQUAL if available.
Or if !cselib_record_memory (or unconditionally) cselib_record_sets
could just enter the REG_EQUAL value as another set.

	Jakub



More information about the Gcc-patches mailing list