On Tue, Jun 20, 2023 at 03:03:19PM +0000, Michael Matz via Gcc wrote:
> Hello,
>
> On Tue, 20 Jun 2023, Jakub Jelinek via Gcc wrote:
>
> > ce1 pass results in emit_conditional_move with
> > (gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (reg:SF 84)
> > operands in the GCC 11 case and so is successfully matched by
> > ix86_expand_fp_movcc as ix86_expand_sse_fp_minmax.
> > But, in GCC 12+, emit_conditional_move is called with
> > (gt (reg/v:SF 83 [ x ]) (reg:SF 84)), (reg/v:SF 83 [ x ]), (const_double:SF
> > 0.0 [0x0.0p+0])
> > instead (reg:SF 84 in both cases contains the (const_double:SF 0.0
> > [0x0.0p+0])
> > value, in the GCC 11 case loaded from memory, in the GCC 12+ case set
> > directly in a move. The reason for the difference is exactly that
> > because cheap SSE constant can be moved directly into a reg, it is done so
> > instead of reusing a pseudo that contains that value already.
>
> But reg84 is _also_ used as operand of emit_conditional_move, so there's
> no reason to not also use it as third operand. It seems more canonical to
> call a function with
>
> X-containing-B, A, B
>
> than with
>
> X-containing-B, A, something-equal-to-B-but-not-B
>
> so either the (const_double) RTL should be used in both, or reg84 should,
> but not a mix. Exactly so to ...
If ifcvt.cc knows that, then sure, but it can't be (easily) worked around on the
backend side...
Jakub
