Re: [PATCH 4/7] ifcvt/optabs: Allow using a CC comparison for emit_conditional_move.

[Robin Dapp <rdapp@linux.ibm.com>]

> Hmm, OK.  Doesn't expanding both versions up-front create the same kind of
> problem that the patch is fixing, in that we expand (and therefore cost)
> both the reversed and unreversed comparison?  Also…
> 
[..]
> 
> …for min/max, I would have expected this swap to create the canonical
> operand order for the min and max too.  What causes it to be rejected?
> 

We should not be expanding two comparisons but only emit (and cost) the 
reversed comparison if expanding the non-reversed one failed.

Regarding the reversal, I checked again - the commit introducing the 
op2/op3 swap is g:deed3da9af697ecf073aea855ecce2d22d85ef71, the 
corresponding test case is gcc.target/i386/pr70465-2.c.  It inlines one 
long double ternary operation into another, probably causing  not for 
multiple sets, mind you.  The situation doesn't occur with double.

>> +
>> +  rtx rev_comparison = NULL_RTX;
>>     bool swapped = false;
>> -  if (swap_commutative_operands_p (op2, op3)
>> -      && ((reversed = reversed_comparison_code_parts (code, op0, op1, NULL))
>> -          != UNKNOWN))
>> +
>> +  code = unsignedp ? unsigned_condition (code) : code;
>> +  comparison = simplify_gen_relational (code, VOIDmode, cmode, op0, op1);
>> +
>> +  if ((reversed = reversed_comparison_code_parts (code, op0, op1, NULL))
>> +      != UNKNOWN)
>>       {
>> -      std::swap (op2, op3);
>> -      code = reversed;
>> -      swapped = true;
>> +      reversed = unsignedp ? unsigned_condition (reversed) : reversed;
> 
> When is this needed?  I'd have expected the reversed from of an unsigned
> code to be naturally unsigned.

This was also introduced by the commit above, probably just repeating 
what was done for the non-reversed comparison.

Regards
  Robin