Richard Sandiford writes: > Adam Nemet <ane...@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
