Sorry for the slow reply.
Robin Dapp via Gcc-patches 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/
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 t
> Before, we had a loop with two iterations that tried "emit_cmov (cond,
> op2, op3)". op2 and op3 can (or even were) If this did not succeed we
> would revert the condition as well as op3 and op3 in-place and try
> again. I found that a bit cumbersome and intended to make this explicit
> b
It might make sense to move:
/* Don't even try if the comparison operands are weird
except that the target supports cbranchcc4. */
if (! general_operand (cmp_a, GET_MODE (cmp_a))
|| ! general_operand (cmp_b, GET_MODE (cmp_b)))
{
if (!have_cbranchcc4
|| GE
Robin Dapp writes:
> Currently we only ever call emit_conditional_move with the comparison
> (as well as its comparands) we got from the jump. Thus, backends are
> going to emit a CC comparison for every conditional move that is being
> generated instead of re-using the existing CC.
> This, combi
Currently we only ever call emit_conditional_move with the comparison
(as well as its comparands) we got from the jump. Thus, backends are
going to emit a CC comparison for every conditional move that is being
generated instead of re-using the existing CC.
This, combined with emitting temporaries
