[Questions] Is there any bit in gimple/rtl to indicate this IR support fast-math or not?

[Segher Boessenkool]

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.kretz@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 <crazylht@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