[cfe-dev] [request] Improve debugging of ffast-math optimizations

[Hal Finkel via cfe-dev]

----- Original Message -----
> From: "C Bergström via cfe-dev" <cfe-dev at lists.llvm.org>
> To: "Mehdi Amini" <mehdi.amini at apple.com>
> Cc: "Gonzalo BG" <gonzalobg88 at gmail.com>, "clang developer list" <cfe-dev at lists.llvm.org>
> Sent: Saturday, April 23, 2016 7:58:00 PM
> Subject: Re: [cfe-dev] [request] Improve debugging of ffast-math	optimizations
> 
> Typically this 1 by 1 process of elimination is automated and also
> ideally done on a reduced test case. Maybe someone around here can
> share their scripts.. (they must exist... Hal?)

With a run script that sets its exit status using a tolerance-based comparison, bugpoint will do a reasonable job. It's more or less like debugging other kinds of miscompiles.

 -Hal 

> If you're starting
> with stable code it's much easier - if you're doing active
> development
> on the codebase as well - I'm empathetic..
> 
> On Sun, Apr 24, 2016 at 6:23 AM, Mehdi Amini via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > On Apr 22, 2016, at 2:48 AM, Gonzalo BG via cfe-dev
> > <cfe-dev at lists.llvm.org>
> > wrote:
> >
> > Finding which code is responsible for violating -ffast-math
> > assumptions is a
> > very tedious task that I do not wish to anybody.
> >
> >
> > Are these "assumptions" documented anywhere?
> >
> > Thanks,
> >
> > --
> > Mehdi
> >
> >
> >
> > Right now when a fast-math assumption is violated the only way I
> > have to
> > debug it is to disable fast math, and step-by-step try each of the
> > more fine
> > grained math optimizations until I find the minimal combination
> > that
> > reproduces the issue. This typically allows me to guess which kinds
> > of
> > operations I should be looking for, and start bisecting. Needles to
> > say this
> > is extremely time consuming. There must be a better way.
> >
> > I would like the behavior of all my programs to not change _much_
> > under the
> > influence of fast math. The only way to achieve this is to manually
> > perform
> > the transformations that fast math is going to perform, like
> > exploiting
> > associativity, and obviously, never violate any of fast-math
> > assumptions.
> >
> > It would be nice to have a warning that detects e.g. associativity
> > transformations, and suggest how to rewrite them to minimize
> > difference in
> > the results between a program compiled with and without fast-math.
> >
> > There is a tool called Herbie [0] that is used by the
> > rust-herbie-lint [1]
> > (worht seeing in action) to improve the accuracy and stability of
> > mathematical operations so maybe something similar could be done to
> > detect
> > some of the transformations that fast-math does and suggest them to
> > the
> > user.
> >
> > At run-time I would like some kind of fast-math sanitizer that
> > catches all
> > cases in which fast-math assumptions are violated (signaling nans,
> > signed
> > zeros, ...). Since the undefined-behavior sanitzer already covers
> > e.g.
> > division by zero, maybe a fast-math check would belong there as
> > well.
> >
> > [0] http://herbie.uwplse.org/
> > [1] https://github.com/mcarton/rust-herbie-lint
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory