A formal description of the nested CPR property (but the usefulness of
such is limited, it seems...)

the reason why we remove the converging flag of LoopBreakers is actually
non-obvious, and has little to do with the termination analysis per se.
Document that with an extensive note and guard it with two test cases.

which can disable cpr altogether (=0), disable nested cpr (=1) or
finetune cpr.

Also includes a testcase for this.

it does nothing that dmdAnalVarApp would not have done before

because the worker is handled specially by the demand analyser, and the
wrapper is expected to be inlined before that.

There are corner cases (such as undersaturated calls) where this loses
information, but nofib does not know any of these.

On the other side it simplifies and removes code, and it makes it easier
to get holdof the DynFlags whenever we create CPR information.

so that the CPR analysis find the real constructor and can return a
nested CPR result.

An alternative would be to look through the unfolding and analize that
(but that would only be a good idea if the wrapper is going to be
inlined afterwards), or special-case wrappers in the demand analyzer.
Both not very nice.

According to nofib: The impact of this is (on code size and allocations)
is ... nil.

in case of a complex case scrunitee.

as otherwise, it could become infinite.

because this is the right-identity to `bothDmdResult`, and this is the
right thing to do in a lazy context.

to detect definite convergence (required for nested CPR).

Notable details:
 * botDmdType is no longer the unit for lubDmdType. So do not use foldr
   lubDmdType botDmdType when combinding the branches of a case, to
   avoid throwing away information.
 * avoid declaring recursive things as terminating for sure, by removing
   the Converges flag from a loop breaker.
 * cprProdSig comes with a Converging flag, so it is removed using
   sigMayDiverge where necessary
 * a data constructor worker is not converging, if it is strict in any
   of its fields.

because they are trivially strict, and the primitive operations do not
have the strictness demand in their demand signature.

Signed-off-by: Austin Seipp <austin@well-typed.com>

End of Cmm pipeline used to be split into two alternative flows,
depending on whether we did proc-point splitting or not. There
was a lot of code duplication between these two branches. But it
wasn't really necessary as the differences can be easily enclosed
within an if-then-else. I observed no impact of this change on
compilation performance.

This tests various properties expected to hold for
quotRem, divMod, div, mod, quot, and rem.

Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

  * CmmRewriteAddignments module was replaced by CmmSink a long
    time ago. That module is now available at
    https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Hoopl/Examples
    wiki page.

  * removeDeadAssignments function was not used and it was also
    moved to the above page.

  * I also nuked some commented out debugging code that was not
    used for 1,5 year.

It turns out that one of the cases in the optimization pass was
a special case of another. I remove that specialization since it
does not have impact on compilation time, and the resulting Cmm
is identical.

Fixes #8585

When emmiting label of a self-recursive tail call (ie. when
performing loopification optimization) we emit the loop header
label after a stack check but before the heap check. The reason is
that tail-recursive functions use constant amount of stack space
so we don't need to repeat the check in every loop. But they can
grow the heap so heap check must be repeated in every call.
See Note [Self-recursive tail calls] and [Self-recursive loop header].

so that one can build a source distribution without downloading the
windows tarballs.

as there is no testsuite/.git any more.