Renato Golin via llvm-dev
2016-Oct-12 17:22 UTC
[llvm-dev] 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"? cheers, --renato
Hal Finkel via llvm-dev
2016-Oct-12 18:33 UTC
[llvm-dev] Matthias` suggestion for "test-suite" tests that are broken at "-Ofast" and are difficult to "repair"
----- 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
Renato Golin via llvm-dev
2016-Oct-12 18:38 UTC
[llvm-dev] Matthias` suggestion for "test-suite" tests that are broken at "-Ofast" and are difficult to "repair"
On 12 October 2016 at 19:33, Hal Finkel <hfinkel at anl.gov> wrote:> 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.Right, that's ok. Means we'll investigate each individual test and make sure the tolerances, sampling or disabling will be done in that order, if all previous attempts failed. cheers, --renato