On Wed, 15 Jun 2022, Jakub Jelinek wrote: > 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?
Ah, that might be a nice way to simplify the fallback indeed. > > 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. Indeed. So I guess OK with the suggested extra argument to the IFN. Thanks, Richard.
