Re: fwprop and CSE const anchor opt

[Adam Nemet <anemet at caviumnetworks dot com>]

Richard Sandiford writes:
> Adam Nemet <anemet@caviumnetworks.com> writes:
> > In order for my CSE const anchor patch to work I needed to drastically lower
> > the cost of immediate addition in the MIPS backend.  This was acceptable as a
> > proof of concept but not in general of course.
> >
> > The problem is with "single-insn"/simple constants.  We would also like these
> > to use const anchors in the hope that the resulting expression would get
> > propagated into MEM expressions.  I was hoping that fwprop would do this
> > propagation for me.  However, since a single-insn constant load is cheaper
> > than an immediate addition (make sense), fwprop is free to propagate either
> > (1) into (2) or (2) into (3) here:
> >
> >   (1) a <- C
> >       |
> >       +--> (2) b <- a + D
> >       |        |
> >       |        +--> (3) mem(b)
> >       |
> >       +--> (4) use(a)
> >
> > Which one it does depends on which one it tries first.  Right now we go in
> > insn order so we'd do (1) to (2) preventing to do (2) to (3) later.
> 
> Probably a dumb question, sorry, but is this only a problem for MIPS when
> C + D is in the range [0x8000, 0xFFFF]?  Or is the (1)->(2) substitution
> somehow succeeding in other cases?

Right and no.  I wasn't very precise saying single-insn constants; I should
have said single-insn constants produced with ORI using the zero register.
(The testcase in PR/33699 is really good :).)

Just to recap the other cases:

* Synthesizing multi-insns constants from const anchors make sense regardless
whether the constant is used as an address so I am adjusting the cost system
to make those stick independent of the context.  I still need to benchmark
this.

* For single-insn constants produced with ADDIU using the zero register, we
don't need const anchors because they can already be used in addresses
offsetting the zero register.

Adam