Make specialisation a bit more aggressive

The patch

    commit c43c981705ec33da92a9ce91eb90f2ecf00be9fe
    Author: Simon Peyton Jones <simonpj@microsoft.com>
    Date:   Fri Oct 23 16:15:51 2009 +0000
    Fix Trac #3591: very tricky specialiser bug

fixed a nasty specialisation bug /for DFuns/.  Eight years
later, this patch

    commit 2b74bd9d8b4c6b20f3e8d9ada12e7db645cc3c19
    Author: Simon Peyton Jones <simonpj@microsoft.com>
    Date:   Wed Jun 7 12:03:51 2017 +0100
    Stop the specialiser generating loopy code

extended it to work for /imported/ DFuns.  But in the process
we lost the fact that it was needed only for DFuns! As a result
we started silently losing useful specialisation for non-DFuns.
But there was no regression test to spot the lossage.

Then, nearly four years later, Andreas filed #19599, which showed
the lossage in high relief.  This patch restores the DFun test,
and adds Note [Avoiding loops (non-DFuns)] to explain why.

This is undoubtedly a very tricky corner of the specialiser,
and one where I would love to have a more solid argument, even a
paper!  But meanwhile I think this fixes the lost specialisations
without introducing any new loops.

I have two regression tests, T19599 and T19599a, so I hope we'll
know if we lose them again in the future.

Vanishingly small effect on nofib.

A couple of compile-time benchmarks improve
  T9872a(normal) ghc/alloc  1660559328.0  1643827784.0  -1.0% GOOD
  T9872c(normal) ghc/alloc  1691359152.0  1672879384.0  -1.1% GOOD
Many others wiggled around a bit.

Metric Decrease:
    T9872a
    T9872c

0 files changed, 0 insertions, 0 deletions