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
