[cfe-dev] [request] Improve debugging of ffast-math optimizations
Hal Finkel via cfe-dev
cfe-dev at lists.llvm.org
Sun Apr 24 08:51:38 PDT 2016
First off, the tool you reference below, rust-herbie-lint, looks really neat:
test.rs:40:5: 40:18 warning: Numerically unstable expression, #[warn(herbie)] on by default
test.rs:40 (a/b + c) * b;
test.rs:40:5: 40:18 help: Try this
test.rs: (c * b) + a;
test.rs:67:5: 67:23 warning: Numerically unstable expression, #[warn(herbie)] on by default
test.rs:67 (a*a + b*b).sqrt();
test.rs:67:5: 67:23 help: Try this
That's awesome! I hope that Clang can develop warnings like this.
Second, we could have a sanitizer mode in which instructions with nnan and ninf flags (and similar) were checked (operands and output) for these special values. Such a sanitizer failing would not always be a concrete problem (sometimes users expect these values might be generated, but they just don't care how they're handled), but many users want a way to determine when and where such values appear. That having been said, the most efficient way to do this (on many architectures) is to enable certain floating-point exceptions. Instrumentation would be much slower. Maybe a sanitizer for these things could take advantage of hardware floating-point exception support somehow.
For optimizations, like traditional reassociation (and reduction vectorization), we could use the backend "remark" feature to give users information on where these apply. On large codes, however, such information would be very noisy. For this to be useful we'd need to think about how to filter, I suspect we'd need to combine it with profiling information, so they we only generated the information on actually-executed (or even hot) paths.
Explaining what the optimization did in terms of source-level variables is something I'm not quite such how to best accomplish in the current infrastructure (perhaps using debug info?). That would be a nice functionality to have, however.
----- Original Message -----
> From: "Gonzalo BG via cfe-dev" <cfe-dev at lists.llvm.org>
> To: "clang developer list" <cfe-dev at lists.llvm.org>
> Sent: Friday, April 22, 2016 4:48:21 AM
> Subject: [cfe-dev] [request] Improve debugging of ffast-math optimizations
> Finding which code is responsible for violating -ffast-math
> assumptions is a very tedious task that I do not wish to anybody.
> 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  that is used by the
> rust-herbie-lint  (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.
>  http://herbie.uwplse.org/
>  https://github.com/mcarton/rust-herbie-lint
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the cfe-dev