https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #0)
> Failed to match this instruction:
> (set (reg:SI 125 [+4 ])
> (minus:SI (minus:SI (reg:SI 127)
> (reg:SI 121 [ b+4 ]))
> (ltu:SI (reg:CC 100 cc)
> (const_int 0 [0]))))
> (set (reg:SI 125 [+4 ])
> (minus:SI (minus:SI (reg:SI 127)
> (reg:SI 121 [ b+4 ]))
> (ltu:SI (reg:CC 100 cc)
> (const_int 0 [0]))))
That is
(set D (minus (minus A B) (X C 0)))
> Successfully matched this instruction:
> (set (reg:SI 125 [+4 ])
> (minus:SI (minus:SI (reg:SI 119 [ a+4 ])
> (ltu:SI (reg:CC 100 cc)
> (const_int 0 [0])))
> (reg:SI 129)))
And this is
(set D (minus (minus A (X C 0)) B))
There are no rules for that afaics.
> These are mathematically equivalent, but because we do not produce
> consistent RTL for them we need two patterns if we are to match both
> alternatives.
Yes; the same is true for quite a few other unusual combinations. Or
not even so very unusual:
(ior (ashift X N) (lshiftrt Y M))
vs.
(ior (lshiftrt Y M) (ashift X N))
is one nasty example, but also reg+reg+reg where one of the regs is
"special" can appear in multiple forms.
> I think both should be canonicalized with the LTU inside the inner MINUS
> expression, but I wouldn't mind if the other were chosen, as long as we were
> consistent.
What would the rule become? What targets would it break, and how?
What makes combine come up with something else for these two cases?
