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

[Richard Sandiford <richard.sandiford@arm.com>]

Sorry for the slow reply.

Robin Dapp via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>> 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.

The (potential) problem is that prepare_cmp_insn can itself emit
instructions.  With the current code we rewind any prepare_cmp_insn
that isn't needed, whereas with the new code we might keep both.

This also means that prepare_cmp_insn calls need to stay inside the:

  saved_pending_stack_adjust save;
  save_pending_stack_adjust (&save);
  last = get_last_insn ();
  do_pending_stack_adjust ();

  …

  delete_insns_since (last);
  restore_pending_stack_adjust (&save);

block.

> 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.

OK, so going back to that revision and using the original SciMark test
case, we first try:

  (lt (reg/v:DF 272 [ ab ])
      (reg/v:DF 271 [ t ]))
  (reg/v:SI 227 [ jp ])
  (subreg:SI (reg:DI 346 [ ivtmp.59 ]) 0)

but i386 doesn't provide a native cbranchdf4 for lt and so the
prepare_cmp_insn fails.  Interesting that we use cbranch<mode>4
as the test for what conditional moves should accept, but I guess
that isn't something to change now.

So the key piece of information that I didn't realise before is
that it was the prepare_cmp_insn that failed, not the mov<mode>cc
expander.  I think we can accomodate that in the new scheme
by doing:

  if (rev_comparison && COMPARISON_P (rev_comparison))
    prepare_cmp_insn (XEXP (rev_comparison, 0), XEXP (rev_comparison, 1),
		      GET_CODE (rev_comparison), NULL_RTX,
		      unsignedp, OPTAB_WIDEN, &rev_comparison, &cmode);

first and then making:

  if (comparison && COMPARISON_P (comparison))
    prepare_cmp_insn (XEXP (comparison, 0), XEXP (comparison, 1),
		      GET_CODE (comparison), NULL_RTX,
		      unsignedp, OPTAB_WIDEN, &comparison, &cmode);

conditional on !rev_comparison.  But maybe the above makes
that moot.

>>> +
>>> +  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.

Yeah, but in the original code, the first reverse_comparison_code_parts
happens outside the loop, before the first unsigned_condition (which
happens inside the loop).  In the new code, the unsigned_condition
happens first, before we try reversing it.

IMO the new order makes more sense than the old one.  But it means that
reversed_comparison_code_parts always sees a comparison of the right
signedness, so we shouldn't need to adjust the result.

Thanks,
Richard