Fix loss-of-SpecConstr bug
authorSimon Peyton Jones <simonpj@microsoft.com>
Tue, 2 May 2017 11:04:44 +0000 (12:04 +0100)
committerSimon Peyton Jones <simonpj@microsoft.com>
Tue, 2 May 2017 11:04:44 +0000 (12:04 +0100)
commit9e47dc451788cce20acb6a8208c56a7e4dbe246b
tree8d1c9cf2a6f8d77f5cc5cbd1db9009583507b505
parentff239787f7170a93f1015bd0f5582772b7b87f0a
Fix loss-of-SpecConstr bug

This bug, reported in Trac #13623 has been present since

  commit b8b3e30a6eedf9f213b8a718573c4827cfa230ba
  Author: Edward Z. Yang <ezyang@cs.stanford.edu>
  Date:   Fri Jun 24 11:03:47 2016 -0700

      Axe RecFlag on TyCons.

SpecConstr tries not to specialise indefinitely, and had a
limit (see Note [Limit recursive specialisation]) that made
use of info about whether or not a data constructor was
"recursive".  This info vanished in the above commit, making
the limit fire much more often -- and indeed it fired in this
test case, in a situation where specialisation is /highly/
desirable.

I refactored the test, to look instead at the number of
iterations of the loop of "and now specialise calls that
arise from the specialisation".  Actually less code, and
more robust.

I also added record field names to a couple of constructors,
and renamed RuleInfo to SpecInfo.
compiler/specialise/SpecConstr.hs
testsuite/tests/perf/should_run/T13623.hs [new file with mode: 0644]
testsuite/tests/perf/should_run/T13623.stdout [new file with mode: 0644]
testsuite/tests/perf/should_run/all.T