https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
--- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #1) > (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)) > Yes, but since (A - B) - C = A - B - C = A - C - B = (A - C) - B we can clearly swap the order of the two RHS operands here. This would be a special rule similar to the rules that we have that rewrite A - (B + C) as (A - B) - C. My suggestion would be that we should have a rule here that re-orders things so that B is the most 'complex' operation and C the simplest, using the normal precedence ordering (complex > REG > CONST). > 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? See suggestion above. I think we might also have a rule that within 'complex' the ordering might be by RTX code number, but that's somewhat arbitrary; thought it is likely to be fairly stable. It would produce a strict canonical ordering for your IOR case above, however. > What targets would it break, and how? Hard to tell, until we try it. Mostly the 'breakage' would be some combine patterns might no-longer match if the target only had one and the ordering were not canonical (leading to some missed optimizations). On targets that have both orderings, some patterns might become redundant and never match unless directly generated by the back-end. > > What makes combine come up with something else for these two cases? Sorry, I don't understand what you're asking here? Why does it produce these two separate canoncializations in one compilation? I've no idea, hence the bug report.
