Canonicalization of compares performed as side-effect operations

[Uros Bizjak]

Hello!

> On Tue, Aug 06, 2019 at 05:49:17PM +0100, Richard Earnshaw (lists) wrote:
>> On 06/08/2019 17:39, Segher Boessenkool wrote:
>> >>>What's wrong with describing the canonical form in your MD?  You'll need
>> >>>some reversed condition code thingy, but that's it?
>> >>
>> >>It doesn't describe what the instruction does.  The negation has a side
>> >>effect of setting the flags, but the flags are swapped because the
>> >>side-effect comparison is swapped from a normal compare.  As I
>> >>mentioned, SELECT_CC_MODE doesn't help because it can't see the context
>> >>and the comparison just looks 'normal'.
>> >
>> >Sure, and we can work on making combine do what you want, but your existing
>> >pattern is *incorrect*.  It needs fixing, and probably before we do other
>> >things.
>>
>> Why is it incorrect?  It's not canonical, sure.  But the cannonical form
>> does NOT describe what the instruction does.
>
> More precisely: not having the canonical form of this in your MD is what
> is incorrect.

There is TARGET_CANONICALIZE_COMPARISON target hook that can solve the
issue here. Please see x86, where we canonicalize
*cmp<X87MODEF:mode>_<SWI24:mode>_i387 via
ix86_canonicalize_comparison. As said in the comment:

  /* The order of operands in x87 ficom compare is forced by combine in
     simplify_comparison () function. Float operator is treated as RTX_OBJ
     with a precedence over other operators and is always put in the first
     place. Swap condition and operands to match ficom instruction.  */

The issue looks similar to me.

Uros.