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

[Hal Finkel via cfe-dev]

----- Original Message -----
> From: "Milian Wolff" <mail at milianw.de>
> To: cfe-dev at lists.llvm.org, "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Gonzalo BG" <gonzalobg88 at gmail.com>
> Sent: Monday, April 25, 2016 4:49:42 AM
> Subject: Re: [cfe-dev] [request] Improve debugging of ffast-math optimizations
> 
> On Sunday, April 24, 2016 10:51:38 AM CEST Hal Finkel via cfe-dev
> wrote:
> > Hi!
> 
> <snip>
> 
> > 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.
> 
> Would it be much more noisy than reports on missed auto-vectorization
> opportunities?

I suspect it would be significantly noisier, because it would be per subexpression, not per loop. We need to think about how to make the information useful. Getting 10s or 100s of remarks that say 'a floating-point operation was reassociated' for every non-trivial line of code with math seems likely useless. As a minimum, we need to figure out how to pull source-level variable names. I think that, realistically, to be useful, the information would need to be presented as you originally implied: we need something that 'decompiles' the IR into source-level expressions so that the user can see what the compiler did with the code. This might be doable if we keep enough debug info around while optimizing, but I'm not sure.

 -Hal

> When I used those, I always piped the output to a file
> and
> browsed it in an editor to find the spots I knew are hot from
> separate
> profiler runs. Not perfect, but certainly doable and helpful and I
> would
> assume much easier to implement on the clang side.
> 
> Cheers
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> 

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