[Bug rtl-optimization/98986] Try matching both orders of commutative RTX operations when there is no canonical order

["segher at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986

--- Comment #6 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #4)
> So this is where the "autogenerated" part comes in.  We should have
> an idea what might be useful and what isn't even worth trying by
> looking at the machine description (which might require exposing
> costs in such form for this case of constants).
> 
> For commutative operands maybe recog itself can be relaxed and
> accept the insn with the "wrong" commutation (or fix it up
> itself) for example.  Or maybe genrecog can magically emit
> commutated variants (like genmatch does for :c annotated
> expression branches).

We could probably derive what things in an RTL expression are commutative (even
if there are many quantities in play), but only allowing the canonical forms in
that is a daunting task.  Something like :c could help; we already have % in
RTL,
but we need more general than that (examples: a+b+c and a*b+c*d should both be
handled some way, since such cases (structure, not necessarily those exact ops)
happen a lot in practice.