Eric Botcazou <ebotca...@adacore.com> writes: >> But that's the problem with trying to do the optimisation in this way. >> We first simplify a truncation of an SImode addition X. Then we simplify >> a zero extension of that truncation. Then we have the opportunity to >> realise that the zero extension wasn't necessary after all, so we actually >> want to undo both simplifications and go back to the original addition >> pattern. So undoing the simplifications is precisely what we're aiming for >> here, again regardless of RISCness. > > In other words, you want to add the reverse transformation in combine.c to > undo the effects of the simplication in simplify-rtx.c? And move the latter > simplification back to combine.c in the process?
No, the second follow-up was about moving the simplification to combine.c and guarding it with !WORD_REGISTER_OPERATIONS, or whatever other check you prefer, so that no undoing is necessary. To be clear, that isn't what I want. :-) It just seems less bad than guarding a simplify-rtx.c operation based on the target. What I really want is to do redundancy elimination as a separate pass, without tying it combine and without doing it the way that combine does. But it's not like I've got time to do that. The quote above was just me griping about the way that, although combine is asking simplify-rtx.c to simplify i1-combined-with-i2, it's actually relying on the simplifications being no-ops, so that the original i1 is still available when i1-with-i2 is further combined into i3 and the redundancy of i2 becomes known, giving i1-with-i3. It just seems like a fragile way to do redundancy elimination. Thanks, Richard
