Eric Botcazou <[email protected]> writes:
>> No, no trivial paths unfortunately. I'd hoped that inlining and
>> jump threading would give us very similar code, but no such luck.
>> condition_to_flags is a table lookup, but then flags_to_condition
>> is a branch tree.
>
> Too bad. Perhaps this would be an interesting optimization exercise.
Yeah. Unfortunately I have a lot of those to get through for GCC 10
already :-)
>> If that's a concern, I can drop the changes to the existing
>> functions and just use the new flags for the follow-on patch.
>
> IMO the net pessimization is a little hard to swallow, although it probably
> doesn't matter much in practice. I'd suggest adding the new logic in every
> case, but keeping the fast path when it's a nop:
>
> enum rtx_code
> swap_condition (enum rtx_code code)
> {
> /* Deal with the trivial cases first. */
> switch (code)
> {
> case EQ:
> case NE:
> case UNORDERED:
> case ORDERED:
> case UNEQ:
> case LTGT:
> return code;
> default:
> break;
> }
>
> unsigned int flags = condition_to_flags (code);
> flags = ((flags & ~(FLAGS_GT | FLAGS_LT))
> | (flags & FLAGS_GT ? FLAGS_LT : 0)
> | (flags & FLAGS_LT ? FLAGS_GT : 0));
> return flags_to_condition (flags, true);
> }
>
> OK with this additional change.
I'm not sure using flags_to_condition really buys anything then,
since you have to think about each individual case to see whether
it belongs in the switch or not. I also don't have any proof
that the no-op cases are the common ones (since adding this
fast path of course slows down the others).
I think I'll just use the new routines for the new optimisation
and leave the existing ones as-is.
Thanks,
Richard
