Hi all, On Thu, Jul 09, 2020 at 10:29:44AM +0200, Jakub Jelinek via Gcc-patches wrote: > On Thu, Jul 09, 2020 at 09:17:46AM +0100, Richard Sandiford wrote: > > If target-independent code is going to optimise for “no subreg operand” > > targets like nvptx, I think it needs to know that the target wants that. > > Isn't that though what the expander is doing in lots of places?
Not nearly enough, in fact. The expander should output very simple code, and let the RTL optimisers figure out what would make good machine code. Doing "optimisations" during expand just leads to worse code (and makes the compiler itself harder to maintain). Expand should translate Gimple to simple RTL, and that is it. A lot of what expand does was useful when people used -O0 and -O1 in production, but is harmful in the modern world. > Force operands into pseudos especially if optimize to hope for better CSE Not just CSE, but pretty much *all* RTL optimisations can do a better job if they start with simple non-obfuscated code. > etc., and hope combine does its job to undo it when it is better to be > propagated? It does, usually. Not if a move is the only thing in a block, but it is RA's job to decide in that case, anyway. > It is true that if res is used several times, then combine will not > propagate it due to multiple uses, Nope, combine can handle that just fine :-) It won't do this if the resulting code is more expensive than what it started with, of course, but combine can handle multiple uses just fine, in general. What it cannot handle well is multiple sets of the same pseudo. You shouldn't do that anyway, combine is not the only pass that will not handle this. > so the question I guess is why as Roger > says we get the same code before/after (which pass undoes that; RA?). combine can do it just fine, in the simpler cases. RA can do more cases. Segher
