On Wed, Jun 15, 2022 at 09:45:25AM +0200, Richard Biener wrote:
> I wonder if that matching to IFN_ATOMIC_BIT_TEST_AND_* should then
> happen at the time we expand the original builtin call to RTL? Or
> did the matching expose secondary optimization opportunities?
I don't see how we could do what optimize_atomic_bit_test_and
and optimize_atomic_op_fetch_cmp_0 do at expansion time.
The back-and-forth is ugly indeed, but it is just the last fallback
if everything else fails, right now -march=i386 only (and actually,
in the IFN_ATOMIC_BIT_TEST_AND_* case it is just theoretical because
the actual optabs don't use FAIL).
Would it be acceptable to you if I simplify the patch by
remembering gimple_call_fn (call) in an extra argument to ifn,
so that we don't have to compute it back and can just quickly
create a CALL_EXPR with the same first 2/3 arguments as the ifn?
> The back-and-forth is a big ugly IMHO and it would suggest we can
> always match to the IFN since we can fall back to the builtin
> call as expansion...?
We can, but if the optab isn't implemented, it won't improve the code in any
way. So it would be wasted work.
Jakub
