driver: pass '-fPIC' option to assembler as well

Summary:
Before the patch '-fPIC' was passed only to C compiler,
but not to assembler itself.

It led to runtime crash in GHC_DYNAMIC_PROGRAMS=YES mode
on sparc32.

Technical details are in 'Note [-fPIC for assembler]'.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: validate on sparc

Reviewers: simonmar, austin, kgardas

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D177
Revert "disable shared libs on sparc (linux/solaris) (fixes #8857)"

This reverts commit 623883f1ed0ee11cc925c4590fb09565403fd231.

The commit a93ab43ab5f40cadbedea2f6342b93c245e91434
    driver: pass '-fPIC' option to assembler as well
fixes shared libraries on sparc at least on linux.

Properly fixes Issue #8857

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Less voluminous output when printing continuations
Refactor unfoldings

There are two main refactorings here

1.  Move the uf_arity field
       out of CoreUnfolding
       into UnfWhen
    It's a lot tidier there.  If I've got this right, no behaviour
    should change.

2.  Define specUnfolding and use it in DsBinds and Specialise
     a) commons-up some shared code
     b) makes sure that Specialise correctly specialises DFun
        unfoldings (which it didn't before)

The two got put together because both ended up interacting in the
specialiser.

They cause zero difference to nofib.
Kill unused setUnfoldingTemplate
Make maybeUnfoldingTemplate respond to DFunUnfoldings

CoreSyn.maybeUnfoldingTemplate is used mainly when specialising,
so make DFunUnfoldings respond to it makes it possible to specialise
them properly.
Make worker/wrapper work on INLINEABLE things

This fixes a long-standing bug: Trac #6056.  The trouble was that
INLINEABLE "used up" the unfolding for the Id, so it couldn't be
worker/wrapper'd by the strictness analyser.

This patch allows the w/w to go ahead, and makes the *worker* INLINEABLE
instead, so it can later be specialised.

However, that doesn't completely solve the problem, because the dictionary
argument (which the specialiser treats specially) may be strict and
hence unpacked by w/w, so now the worker won't be specilialised after all.

Solution: never unpack dictionary arguments, which is done by the isClassTyCon
          test in WwLib.deepSplitProductType_maybe
Specialise Eq, Ord, Read, Show at Int, Char, String

These instances are quite common, so it's good to have
pre-specialised versions available
Move the Enum Word instance into GHC.Enum

This just avoids an unnecessary orphan instance.
All the other instances for "earlier" types are in GHC.Enum already.
Don't float out (classop dict e1 e2)

A class op applied to a dictionary doesn't do much work, so it's not
a great idea to float it out (except possibly to the top level.

See Note [Floating over-saturated applications] in SetLevels

I also renamed "floatOutPartialApplications" to "floatOutOverSatApps";
the former is deeply confusing, since there is no partial application
involved -- quite the reverse, it is *over* saturated.
Slightly improve fusion rules for 'take'
Specialise monad functions, and make them INLINEABLE

Specialise liftM, foldM, etc, and make them specialisable
for new monads at their call sites by using INLINEABLE
Wibbles to "...plus N others" error message about instances in scope

I this this arises from my de-orphaning the Enum Word instance
More SPEC rules fire
Compiler performance increases -- yay!
Add -fspecialise-aggressively

This flag specialises any imported overloaded function that has an
unfolding, whether or not it was marked INLINEABLE.

We get a lot of orphan SPEC rules as a result, but that doesn't matter
provided we don't treat orphan auto-generated rules as causing the module
itself to be an orphan module.  See Note [Orphans and auto-generated rules]
in MkIface.
Fix an egregious bug in the NonRec case of bindFreeVars

We were missing the free variables of rules etc.  It's correct
for Rec but wrong for NonRec.  I'm not sure how this bug hasn't
bitten us before, but it cropped up when I was doing trimAutoRules.
Make tidyProgram discard speculative specialisation rules

The new function TidyPgm.trimAutoRules discards bindings and
rules that were useful, but now have served their purpose.

See Note [Trimming auto rules] in TidyPgm
Comments only
Run float-inwards immediately before the strictness analyser.

Doing so pushes bindings nearer their use site and hence makes
them more likely to be strict. These bindings might only show
up after the inlining from simplification.  Example in fulsom,
Csg.calc, where an arg of timesDouble thereby becomes strict.

Very few programs are affected, but it's basically good news.

        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
            fft          -0.2%     +1.3%      0.06      0.06    -10.0%
         fulsom          -0.0%     -2.6%     -4.3%     -4.7%     -6.7%
         simple          +0.0%     -0.8%      0.0%      0.0%      0.0%
--------------------------------------------------------------------------------
            Min          -0.5%     -2.6%     -4.5%     -4.7%    -10.0%
            Max          +0.1%     +1.3%     +3.3%     +3.4%     +2.6%
 Geometric Mean          -0.0%     -0.0%     -0.6%     -0.6%     -0.2%

The lossage in fft is the loss of detecting a common sub-expression,
and can be fixed by doing earlier CSE.  But that is in any case a bit
of a fluke so I don't mind losing it in exchange for this more reliable
gain.