DPH tests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

DPH tests

Jan Stolarek
When I do full testsuite run (either with 'make fulltest' or './validate --slow') there is a bunch of DPH tests which take Very Long Time to run (approx. half of the time needed to run testsuite, if not more). These tests are consistently failing. What would DPH team and others say to disabling these tests temporarily? I think that since February there hasn't been much going on in the DPH repository and compiler/vectorize folder. We'd have thhese tests enabled again when work on DPH picks up again.

Janek



Reply | Threaded
Open this post in threaded view
|

DPH tests

Ben Lippmeier-2

On 16/08/2013, at 12:28 AM, Jan Stolarek wrote:

> When I do full testsuite run (either with 'make fulltest' or './validate --slow') there is a bunch of DPH tests which take Very Long Time to run (approx. half of the time needed to run testsuite, if not more). These tests are consistently failing.

Well, if you say --slow then it's not supposed to take a short amount of time...

We need to keep some tests running because the DPH vectoriser is part of GHC and we need to protect it from rotting.

However, the current backend code which is likely causing the problem will eventually be replaced. If you add the flag -fno-spec-constr when building with the --slow way then this may solve the problem. Adding -fno-spec-constr will prevent the compiled code from fusing properly, but we're going to change the fusion system anyway.

> What would DPH team and others say to disabling these tests temporarily? I think that since February there hasn't been much going on in the DPH repository and compiler/vectorize folder. We'd have thhese tests enabled again when work on DPH picks up again.

We need to keep testing the vectoriser to ensure it doesn't rot. However, the code likely to be causing the problem is in the backend library, and adding -fno-spec-constr (or otherwise reducing the optimisation level) should fix it.

TooMuchInlining + ForceSpecConstr = BOOM!.

Ben.




Reply | Threaded
Open this post in threaded view
|

DPH tests

Ben Lippmeier-2

On 16/08/2013, at 1:30 PM, Ben Lippmeier wrote:

>
> On 16/08/2013, at 12:28 AM, Jan Stolarek wrote:
>
>> When I do full testsuite run (either with 'make fulltest' or './validate --slow') there is a bunch of DPH tests which take Very Long Time to run (approx. half of the time needed to run testsuite, if not more). These tests are consistently failing.
>
> Well, if you say --slow then it's not supposed to take a short amount of time...

BTW, ideally the person that pushed the patch that caused these tests to start failing would have noticed and asked for help then, but that didn't happen...

If you disable the tests then you're accepting a regression in the simplifier, but perhaps that doesn't matter anymore.

Ben.




Reply | Threaded
Open this post in threaded view
|

DPH tests

Simon Peyton Jones
In reply to this post by Ben Lippmeier-2
| However, the code likely to be causing the problem is in the backend
| library, and adding -fno-spec-constr (or otherwise reducing the
| optimisation level) should fix it.
|
| TooMuchInlining + ForceSpecConstr = BOOM!.

Yes, this is a delicate point.  DPH relies on aggressive inlining, and aggressive use of SpecConstr.  These are not things that it's easy for someone unfamiliar with what's going on to debug.  Amos was working on the SpecConstr part, I believe.

Ben, would you be able to look at the failing tests and see what's going on?  There isn't much point in running them if they fail anyway -- then we aren't checking that the vectoriser is working.

If there is something I can do to help, just say.

Simon



Reply | Threaded
Open this post in threaded view
|

DPH tests

Ben Lippmeier-2

On 16/08/2013, at 16:58 , Simon Peyton-Jones <simonpj at microsoft.com> wrote:

> Ben, would you be able to look at the failing tests and see what's going on?  There isn't much point in running them if they fail anyway -- then we aren't checking that the vectoriser is working.


Yes, I will when I can build the head again. My recent attempt failed with linker errors, but that might just be me.

Ben.