On 21/10/2019 16:46, Richard Earnshaw (lists) wrote:
On 19/10/2019 17:17, Segher Boessenkool wrote:
Yes, but combine should have removed the move in a 2->1 combination
already, if it is beneficial: both 18->7 and 7->22 should have combined
just fine. This also points to a potential target problem: why are those
two combinations not allowed?
In this case it's because we have a generic pattern for
reg = const - reg - ltu(ccreg)
and the specific case of const == 1, which is then re-ordered as
reg = (1 - ltu(ccreg)) - reg
=> reg = geu(ccreg) - reg
and we don't have a pattern for that. It would be possible to write one
if really needed, but because the GEU has to match several different
modes, it's a bit fiddly and results in a lot of code for not much real
benefit.
I was thinking about this some more last night and realised I already
had all the logic in place to do this.
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01569.html
So now we will do the right thing in this particular case. I still
think, however, that with the current combine approach, costing reg-reg
pseudo moves at 2 rather than 4 is a useful safeguard to have.
R.
