On Wed, Jun 25, 2025 at 11:39 AM Richard Biener <richard.guent...@gmail.com> wrote: > > 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.
Can you check again after r16-1731-g08bdb6b4a32f1f? Thanks, Richard. > > Richard. > > > > > Alexander
