Adam Nemet <ane...@caviumnetworks.com> writes: > 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 :).)
OK. I suppose addresses in that range aren't really going to be used in practice, but I can see it's good to be thorough if we can be. > * 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. Out of interest, what sort of changes did you need to make? Do you care about the cases where rtx_costs is applied to a pattern that won't later be checked by recog (such as the calls from the expander)? Or do you just care about the cases where rtx_costs is used to check whether a validate_change would be profitable? (I was going to launch into a bit of background about the current MIPS constant costs, but I thought I'd better ask first, in case it ends up deflecting the thread too much.) Richard
