On Tue, Jun 24, 2025 at 5:25 PM Alexander Monakov <amona...@ispras.ru> wrote: > > > I'd say we want to fix these kind of things before switching the default. > > Can > > you file bugreports for the distinct issues you noticed when adjusting the > > testcases? > > Sure, filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120808 for the most > frequently hit issue on x86 for now.
Thanks. So almost all issues arise because the FMAs are then introduced early (and possible folding with negates is done late). At some point we've arranged FMAs to be produced after vectorization only (there might be targets with scalar FMA but no vector FMA for example). It shouldn't be too hard to handle FMAs during vectorization but having a mix will certainly complicate things. Likewise undoing FMA creation when there's no vector FMA would rely on detecting whether the FMA was introduced by the compiler or the middle-end (I suppose builtin vs. IFN might do the job here). > > I suppose they are reproducible as well when using the C fma() function > > directly? > > No, unfortunately there are multiple issues with fma builtin: > > 1) __builtin_fma does not accept generic vector types indeed, you'd have to declare an OMP SIMD fma variant but that will not be recognized as fma or .FMA then I think. > 2) we have FMS FNMA FNMS FMADDSUB FMSUBADD internal functions, but > no corresponding builtins These are direct optab internal functions. I'm not sure we want builtins for all of those, fma () with negated arguments should do fine. > 3) __builtin_fma and .FMA internal function are not the same in the > middle-end, > I reported one instance arising from that in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109892 The builtin and the internal function should behave the same, in this case it's again late vs. early exposal of FMA. I am testing partial fixes for these issues. Richard. > > Alexander
