[llvm-dev] Matthias` suggestion for "test-suite" tests that are broken at "-Ofast" and are difficult to "repair"

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Renato Golin" <renato.golin at linaro.org>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Abe Skolnik" <a.skolnik at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias Braun" <mbraun at apple.com>
> Sent: Wednesday, October 12, 2016 12:22:12 PM
> Subject: Re: Matthias` suggestion for "test-suite" tests that are broken at "-Ofast" and are difficult to "repair"
> 
> On 12 October 2016 at 17:09, Hal Finkel <hfinkel at anl.gov> wrote:
> >> I accept Matthias` proposal, and I propose that the above be used
> >> for
> >> wherever "really fixing"
> >> the FP problems with a test is beyond a reasonable effort+time
> >> level.
> >>  This email is to check
> >> acceptance [or lack thereof] of the above.
> >
> > This makes sense to me. I think we should set this up so that the
> > tests are enabled by default, and then we specifically disable
> > those tests for which we've determined that is the best practical
> > solution.
> 
> With -ffast-math, all bets are off, and it makes no sense to check
> against good values, I agree.
> 
> But the benchmarking mode could be run with -ffast-math, and you'd
> still want to make sure it works to some level. I mean, we run SPEC
> with -ffast-math and it's not that bad, so it should be doable.
> 
> But from a test point of view, what sense does it make to run with
> -ffast-math if you'll discard all "problematic" FP tests? Why run the
> tests at all in that config if they're not meaningful?
> 
> I'm not against marking them off for fast-math, I'm just honestly
> trying to understand what the point of it is... simply put: "what is
> the meaning of saying all integer and some non-previously-failing FP
> tests `pass` with -ffast-math"?

I think it depends on what "problematic" means. I want to keep those that we can check by just using a larger (but still reasonable) tolerance, smaller number of iterations, etc. We should only disable the ones for which there is not another reasonable solution.

 -Hal

> 
> cheers,
> --renato
> 

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory