Hi! On Tue, Apr 07, 2020 at 10:52:10AM +0100, Richard Earnshaw (lists) wrote: > On 06/04/2020 12:19, Richard Sandiford wrote: > > "Richard Earnshaw (lists)" <richard.earns...@arm.com> writes: > >> Yes. It surprised me, when doing the aarch32 version, just how often > >> the mid-end parts of the compiler were able to reason about parts of the > >> parallel insn and optimize things accordingly (eg propagating the truth > >> of the comparison). If you use an unspec that can never happen. > > > > That could be changed though. E.g. we could add something like a > > simplify_unspec target hook if this becomes a problem (either here > > or for other unspecs). A fancy implementation could even use > > match.pd-style rules in the .md file. > > I really don't like that. It sounds like the top of a long slippery > slope. What about all the other cases where the RTL is comprehended by > the mid-end?
Same here. And the interesting transforms are not done in simplify-rtx anyway, but in combine: simplify-rtx should only ever make a *simplified* representation, while combine makes a (single!) choice that works out the best in practice. You do need a few separate patterns (for reg, 0, pos, -1, other neg, for example), but then everything automatically works. The canonical way to write these insns is different for different constants, that is all. Segher
