[llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Thu Nov 17 13:03:00 PST 2016
----- Original Message -----
> From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Mehdi Amini" <mehdi.amini at apple.com>
> Cc: llvm-dev at lists.llvm.org, "cfe-dev" <cfe-dev at lists.llvm.org>
> Sent: Thursday, November 17, 2016 11:43:33 AM
> Subject: Re: [llvm-dev] RFC: Consider changing the semantics of
> 'fast' flag implying all fast-math-flags
> > On Nov 17, 2016, at 9:10 AM, Mehdi Amini via llvm-dev <
> > llvm-dev at lists.llvm.org > wrote:
>
> > > On Nov 17, 2016, at 9:00 AM, Sanjay Patel <
> > > spatel at rotateright.com
> > > >
> > > wrote:
> >
>
> > > If we take this argument to its end: any one of those relaxed FP
> > > settings *guarantees* that we cannot ensure that the result will
> > > be
> > > the same between two versions of clang. Therefore, we can no-op
> > > all
> > > of them, and greatly simplify the optimizer.
> >
>
> > I don’t understand the logic here.
>
> I understand now, and I think I answered below: yes we “can" no-op
> all of them, and no we don’t do it because they are valuable,
> because we find them useful, not because GCC expose them on its
> command line.
I think this is exactly right. We should support these flags because they're useful to our users (which they are). We should support reasonable subsetting of fast-math because that's useful to our users (which it is to the extent that we currently support and will be more useful once we can separately toggle reassociation, etc.).
-Hal
> —
> Mehdi
> > > I know that's not what you're advocating, but the suggestion that
> > > we
> > > remove 'arcp' is the first step on that path. We can't do that.
> > > We
> > > must make a good faith effort to support these flags.
> >
>
> > I disagree, we can do it if don’t see any perceived value.
>
> > Saying “gcc has this option” does not mean we have to mimic its
> > behavior if it does not make sense to us.
>
> > Note: *I* am not in favor of removing arcp, even though I don’t
> > believe Warren’s use-case is really compelling.
>
> > —
>
> > Mehdi
>
> > > On Thu, Nov 17, 2016 at 9:31 AM, Mehdi Amini <
> > > mehdi.amini at apple.com
> > > > wrote:
> >
>
> > > > > On Nov 17, 2016, at 8:30 AM, Mehdi Amini <
> > > > > mehdi.amini at apple.com
> > > > > >
> > > > > wrote:
> > > >
> > >
> >
>
> > > > > > On Nov 17, 2016, at 8:03 AM, Sanjay Patel <
> > > > > > spatel at rotateright.com
> > > > > > >
> > > > > > wrote:
> > > > >
> > > >
> > >
> >
>
> > > > > > On Thu, Nov 17, 2016 at 2:31 AM, Nicolai Hähnle via
> > > > > > llvm-dev
> > > > > > <
> > > > > > llvm-dev at lists.llvm.org > wrote:
> > > > >
> > > >
> > >
> >
>
> > > > > > > On 17.11.2016 09:51, Ristow, Warren wrote:
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > Those are all good points. Your reassociation point in
> > > > > > > > the
> > > > > > > > context
> > > > > > > > of
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > inlining is particularly interesting.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > FWIW, we also have a case where a customer wants
> > > > > > > > '-fno-associative-math'
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > to suppress reassociation under '-ffastmath'. It would
> > > > > > > > take
> > > > > > > > me
> > > > > > > > a
> > > > > > > > while
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > to find the specifics of the issue, but it was (if my
> > > > > > > > memory
> > > > > > > > is
> > > > > > > > right)
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > more of a real use-case. (That is to say, the code that
> > > > > > > > was
> > > > > > > > "failing"
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > due to reassociation didn't have an obvious fix like
> > > > > > > > the
> > > > > > > > reciprocal
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > situation, here, other than to turn off fast-math.) In
> > > > > > > > fact,
> > > > > > > > the
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > request to suppress reassociation was the motivation
> > > > > > > > for
> > > > > > > > creating
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > PR27372 in the first place (which eventually fed into
> > > > > > > > this
> > > > > > > > thread).
> > > > > > > > I
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > have to say that on the reassociation point, my concern
> > > > > > > > is
> > > > > > > > that
> > > > > > > > to
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > really suppress that, we will have to suppress so much,
> > > > > > > > that
> > > > > > > > there
> > > > > > > > will
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > hardly be any point in using -ffast-math.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > I'd say your comments here are very similar to what
> > > > > > > > Nicolai
> > > > > > > > said
> > > > > > > > in
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > another subthread of this discussion:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > > > I'd be really curious to know if there is anybody
> > > > > > > > > > who
> > > > > > > > > > really
> > > > > > > > > > needs
> > > > > > > > > > arcp
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > > > without fp-contract=fast or vice versa, or who
> > > > > > > > > > needs
> > > > > > > > > > both
> > > > > > > > > > of
> > > > > > > > > > these
> > > > > > > > > > but
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > > > not the X*log2(0.5*Y) transform you mentioned, and
> > > > > > > > > > so
> > > > > > > > > > on.[1]
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > > > ...
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > > > [1] One case I _can_ think of (and which may have
> > > > > > > > > > been
> > > > > > > > > > a
> > > > > > > > > > reason
> > > > > > > > > > for
> > > > > > > > > > the
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > > > proliferation of flags in the first place) is
> > > > > > > > > > somebody
> > > > > > > > > > who
> > > > > > > > > > enables
> > > > > > > > > > fast
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > > > math, but then doesn't want their results to change
> > > > > > > > > > when
> > > > > > > > > > they
> > > > > > > > > > update
> > > > > > > > > > the
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > > > compiler and get a new set of optimizations. But
> > > > > > > > > > IMO
> > > > > > > > > > that's
> > > > > > > > > > a
> > > > > > > > > > use
> > > > > > > > > > case
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > > > that should be explicitly rejected.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > I think those are all really good points, and an
> > > > > > > > argument
> > > > > > > > can
> > > > > > > > be
> > > > > > > > made
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > that when -ffast-math gives you results you don't want,
> > > > > > > > then
> > > > > > > > you
> > > > > > > > just
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > have to turn it off. Essentially, the user can't "have
> > > > > > > > his
> > > > > > > > cake
> > > > > > > > and
> > > > > > > > eat
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > it too".
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > All that said, I think we (the company I work for,
> > > > > > > > Sony)
> > > > > > > > will
> > > > > > > > have
> > > > > > > > to
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > implement support for these switches. It comes down to
> > > > > > > > GCC
> > > > > > > > has
> > > > > > > > these
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > switches (e.g., -fno-reciprocal-math and
> > > > > > > > -fno-associative-math),
> > > > > > > > and
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > they do suppress the transformations for our customers.
> > > > > > > > They
> > > > > > > > switch
> > > > > > > > to
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > Clang/LLVM, they use the same switches, and it doesn't
> > > > > > > > "work".
> > > > > > > > So
> > > > > > > > as
> > > > > > > > a
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > practical matter, I think we will support them. Whether
> > > > > > > > the
> > > > > > > > LLVM
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > community in general feels that that's required, is
> > > > > > > > another
> > > > > > > > question.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > Until for your recent comments here, and Nicolai's
> > > > > > > > comments
> > > > > > > > above,
> > > > > > > > I
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > would have thought the answer was clearly yes. But
> > > > > > > > maybe
> > > > > > > > that's
> > > > > > > > not
> > > > > > > > the
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > case.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > In summary, irrespective of any (subjective?)
> > > > > > > > assessment
> > > > > > > > of
> > > > > > > > how
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > legitimate a particular use-case is, do we want
> > > > > > > > switches
> > > > > > > > like:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > -ffast-math -fno-reciprocal-math
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > -ffast-math -fno-associative-math
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > to work?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > For me, the answer is yes, because I have multiple
> > > > > > > > customers
> > > > > > > > that
> > > > > > > > tell
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > me they really want to leave -ffast-math on, but they
> > > > > > > > want
> > > > > > > > to
> > > > > > > > be
> > > > > > > > able
> > > > > > > > to
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > disable these sub-categories. I've been approaching
> > > > > > > > this
> > > > > > > > under
> > > > > > > > the
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > > assumption that the answer is yes for the Clang/LLVM
> > > > > > > > community
> > > > > > > > in
> > > > > > > > general.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > I feel your pain, but I'm not convinced yet that this is
> > > > > > > really
> > > > > > > the
> > > > > > > right approach.
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > It sounds like the customers (a) want fast-math in
> > > > > > > general
> > > > > > > but
> > > > > > > (b)
> > > > > > > have some specific parts of the code where it breaks
> > > > > > > things.
> > > > > > > What
> > > > > > > about having them disable fast-math on a more
> > > > > > > fine-grained
> > > > > > > scope,
> > > > > > > e.g. via something like an __attribute__(no_fast_math)
> > > > > > > function
> > > > > > > attribute at the C++ source level?
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > > Then the problematic piece of code might be slower (since
> > > > > > > all
> > > > > > > of
> > > > > > > fast-math is disabled), but the rest of the code would
> > > > > > > likely
> > > > > > > be
> > > > > > > faster (since it benefits from all of fast-math instead
> > > > > > > of
> > > > > > > just
> > > > > > > a
> > > > > > > subset).
> > > > > >
> > > > >
> > > >
> > >
> >
>
> > > > > > This is suggesting source code changes to customers that
> > > > > > are
> > > > > > switching compilers, but (as Warren hinted at) one of the
> > > > > > stated
> > > > > > goals of clang is GCC compatibility:
> > > > >
> > > >
> > >
> >
>
> > > > > > http://clang.llvm.org/
> > > > >
> > > >
> > >
> >
>
> > > > > We don’t aim at being bug-to-bug compatible though.
> > > >
> > >
> >
>
> > > > > I believe we are compatible in terms of command line
> > > > > invocation,
> > > > > even
> > > > > if some gcc flags are no-op in clang.
> > > >
> > >
> >
>
> > > > > > If that's still true, it means (barring anything that we
> > > > > > explicitly
> > > > > > document and choose not to support), we should support
> > > > > > GCC's
> > > > > > FP
> > > > > > options:
> > > > >
> > > >
> > >
> >
>
> > > > > > https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options
> > > > >
> > > >
> > >
> >
>
> > > > > > -ffp-contract=style
> > > > >
> > > >
> > >
> >
>
> > > > > > -ffast-math
> > > > >
> > > >
> > >
> >
>
> > > > > > -fno-math-errno
> > > > >
> > > >
> > >
> >
>
> > > > > > -funsafe-math-optimizations
> > > > >
> > > >
> > >
> >
>
> > > > > > -fassociative-math
> > > > >
> > > >
> > >
> >
>
> > > > > > -freciprocal-math
> > > > >
> > > >
> > >
> >
>
> > > > > > -ffinite-math-only
> > > > >
> > > >
> > >
> >
>
> > > > > > -fno-signed-zeros
> > > > >
> > > >
> > >
> >
>
> > > > > > -fno-trapping-math
> > > > >
> > > >
> > >
> >
>
> > > > > > -frounding-math
> > > > >
> > > >
> > >
> >
>
> > > > > > -fsignaling-nans
> > > > >
> > > >
> > >
> >
>
> > > > > > -fsingle-precision-constant
> > > > >
> > > >
> > >
> >
>
> > > > > > etc, and the relevant negations of these options. We can't
> > > > > > predict
> > > > > > how customers will choose to chain these together, so I
> > > > > > think
> > > > > > the
> > > > > > LLVM optimizer and backend designs should accommodate all
> > > > > > possibilities derived from those clang flags. This includes
> > > > > > (because
> > > > > > I've seen this requested) using relaxed FP modes and
> > > > > > simultaneously
> > > > > > enabling some subset of FP exceptions. (I know it sounds
> > > > > > crazy...
> > > > > > :)
> > > > > > )
> > > > >
> > > >
> > >
> >
>
> > > > > I am not convinced, because when disabling IEEE compliance we
> > > > > can’t
> > > > > even ensure that the result will be the same between two
> > > > > versions
> > > > > of
> > > > > clang (indeed it won’t in many/most real-world cases), the
> > > > > claim
> > > > > that we are “GCC compatible” has not much value here: the
> > > > > code
> > > > > can
> > > > > still break when built with clang and not when built with
> > > > > GCC,
> > > > > even
> > > > > when disabling fast-math.
> > > >
> > >
> >
>
> > > > The last part should read “even when disabling reciprocal”
> > >
> >
>
> > > > —
> > >
> >
>
> > > > Mehdi
> > >
> >
>
> > > > > —
> > > >
> > >
> >
>
> > > > > Mehdi
> > > >
> > >
> >
>
> > _______________________________________________
>
> > LLVM Developers mailing list
>
> > llvm-dev at lists.llvm.org
>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/f753d3e0/attachment.html>
More information about the llvm-dev
mailing list