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
```
typedefunsignedshortv8hu __attribute__((vector_size(16)));
voidg(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.
```
/* Try to build RES_OP, which is known to be a call to FN. Return null
if the target doesn't support the function. */
staticgcall*
build_call_internal(internal_fnfn, gimple_match_op*res_op)
```
Thanks
Abhishek
