GitLab

This required various build system changes to get the build to go
through.

In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs
to find their libraries. In the future, we might change the inplace tree
to be the same shape as an installed tree instead. However, this would
mean changing the way we do installation, as currently we use cabal's
installation methods to install the libraries, but that only works if
the libraries are under libraries/foo/dist-install/build/..., rather
than in inplace/lib/...

Some binaries are installed in lib/, so if we wanted them to have a
shell wrapper then under the old scheme both the binary and the wrapper
would be installed under lib/. Now the binary is put under lib/bin/,
leaving lib/ for the wrapper.

This makes it easier to ensure that we get consistent consistency
checking, e.g. that
    -f1 -f2
will do the same checks as
    -f2 -f1

I think that some of the checks were bogus before, but hopefully
all are correct now.

It's still the case that
    -dynamic -static
will leave -fPIC enabled, but it's tricky to avoid that, and we already
have similar situations where for example
    -XRankNTypes -XNoRankNTypes
will leave ExplicitForAll enabled.

We used to add the options when the way was enabled, but this caused
problems with the static/dynamic choice, as once the 'dynamic' options
had been added it wasn't easy to remove them. We therefore didn't allow
-static on the commandline if we'd already seen -static, which kludged
around the issue.

But apart from being unsatisfactory in the first place, this is a
problem if we want to allow -dynamic being on by default, as there
wouldn't be any way to turn it off.

So now we add C/CPP/linker flags required by the 'way's when flags
are requested, rather than during flag parsing.

Rather than having a separate
    foo_INSTALL_SHELL_WRAPPER
variable, we just use
    foo_INSTALL && foo_SHELL_WRAPPER

The current fix is relatively dumb as far as where to add HpLim
checks: it will always perform a check unless we know that we're
returning from a closure or we are doing a non let-no-escape case
analysis.  The performance impact on the nofib suite looks like this:

            Min          +5.7%     -0.0%     -6.5%     -6.4%    -50.0%
            Max          +6.3%     +5.8%     +5.0%     +5.5%     +0.8%
 Geometric Mean          +6.2%     +0.1%     +0.5%     +0.5%     -0.8%

Overall, the executable bloat is the biggest problem, so we keep the old
omit-yields optimization on by default. Remember that if you need an
interruptibility guarantee, you need to recompile all of your libraries
with -fno-omit-yields.

A better fix would involve only inserting the yields necessary to break
loops; this is left as future work.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>

It's no longer needed in order to build the compiler itself.

This is a hopefully temporary measure until the new SRT design is
implemeented.

Improvements:

 - we now turn off the timer signal in the non-threaded RTS after
   idleGCDelay.  This should make the xmonad users on #5991 happy.

 - we now turn off the timer signal after idleGCDelay even if the
   idle GC is disabled with +RTS -I0.

 - we now do *not* turn off the timer when profiling.

 - more comments to explain the meaning of the various ACTIVITY_*
   values

This reverts commit dd24d6bc.

This attempt to fix the problem was misguided: the program might be
stuck in a foreign call rather than awaitEvent(), and then the timer
signal will never get disabled.  The only way to turn off the timer
signal in this case is in the timer interrupt handler itself.

We only warn when the method is used, not when it is defined as part
of an instance.

Object sizes still unchanged.

No size changes in the non-debug object files

This broke with the changes to the pinned object handling in
67f4ab7e.

The program in #7257 was spending 90% of its time counting the live
data in gen->large_objects.  We already avoid doing this for small
objects, but in this example the old generation was full of large
objects (actually pinned ByteStrings).

Forcing large allocations here can creates serious fragmentation in
some cases, and since the large allocations are only a small
optimisation we should allow the nursery to hoover up small blocks
before allocating large chunks.