On Thu, May 14, 2026 at 12:47 PM Abhishek Kaushik <[email protected]> wrote: > > Hello, > > On 5/11/26 2:27 PM, Richard Biener wrote: > > what needs to be double-checked is whether we have fallback RTL expansion > for the case the target has FMA but not FNMA - I think we don't, we're using > direct-optab expansion. > > The only target I could find that supports FMA but not FNMA was powerpc, and > this code > > ``` > > typedef unsigned short v8hu __attribute__((vector_size(16))); > void g(v8hu *a, v8hu *b, v8hu *c) > { > *c -= (*a * *b); > } > > ``` > > when compiled with `-O3 -maltivec -fdump-tree-widening_mul-folding` shows > that the pattern for FNMA was matched but the replacement was not done. > > ``` > > Applying pattern match.pd:9920, gimple-match-3.cc:8139 > Generated FMA _5 = .FMA (_3, _11, _1); > > ``` > > This is because `maybe_push_res_to_seq` calls `build_call_internal` which has > the `direct_internal_fn_supported_p` guard.
Hmm, I keep forgetting this. > ``` > > /* Try to build RES_OP, which is known to be a call to FN. Return null > if the target doesn't support the function. */ > static gcall * > build_call_internal (internal_fn fn, gimple_match_op *res_op) > > ``` > > Thanks > > Abhishek
