On Wed, Jul 14, 2021 at 09:39:42AM +0200, Richard Biener via Gcc-help wrote: > On Wed, Jul 14, 2021 at 9:00 AM Hongtao Liu via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > On Wed, Jul 14, 2021 at 2:39 PM Matthias Kretz <m.kr...@gsi.de> wrote: > > > > > > On Wednesday, 14 July 2021 07:18:29 CEST Hongtao Liu via Gcc-help wrote: > > > > On Wed, Jul 14, 2021 at 1:15 PM Hongtao Liu <crazy...@gmail.com> wrote: > > > > > Hi: > > > > > The original problem was that some users wanted the cmdline option > > > > > > > > > > -ffast-math not to act on intrinsic production code. > > > > > > This sounds like the users want intrinsics to map *directly* to the > > Thanks for the reply. > > I think the users want the mixed usage of fast-math and no-fast-math. > > > corresponding instruction. If that's the case such users should use inline > > > assembly, IMHO. If you compile a TU with -ffast-math then *all* > > > floating-point > > > operations are affected. Yes, more control over where to use fast-math > > > and the > > > ability to mix fast-math and no-fast-math without risking ODR violations > > > would > > > be great. But that's a larger issue, and one that would ideally be solved > > > in > > > WG14/WG21. > > hmm, guess it would need a lot of work.
Yes. And the biggest part of that is defining what the actual semantics of this should be! Code compiled with -ffast-math is allowed to do completely *anything* if ever it encounters an infinity or denormal, and the sign of zeroes can flip randomly, etc. It cannot interoperate with code compiled with -fno-fast-math in general, unless much care is taken. > -ffast-math decomposes to quite some flag_* and those generally are not > reflected into the IL but can be different per function (and then > prevent inlining). Yeah. And for most of those sub-flags you have the problems I talked about above. > Note some people do like to have their intrisic code optimized, so there's > likely conflicting interest here. If people do not want anything optimised they should use -O0, or write assembler code instead. GCC in general optimises where it can, as any good compiler should. There are various facilities for preventing optimisations in much more targeted places of course -- and most of those do not tell the compiler "do not do X", but they instead say "here Y happens, and you do not know the details of that", effectively telling the compiler "hands off!" Segher
