On 06/08/2019 18:39, Uros Bizjak wrote: > 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. >
That hook can't help as it can't see anything other than the operands of the compare, and from the operands it looks as though the operands should be swapped. To correctly canonicalize this you need the whole parallel, or some other hint that the operation is a side-effect of another operation. R. > Uros. >
