GitLab

This is a little tricky.  See Note [Original module] in MkIface.

This patch should have no effect; it's mainly comments, layout,
plus this contructor name change.

I've forgotten the precise details already, but this patch
significantly refactors the way newtypes are handled, fixes
the foreign-export problem Trac #736 (which concerned newtypes),
and gets rid of a bogus unsafeCoerce in the foreign export
desugaring.

See Note [Inline candidates] in OccurAnal.  We were getting a recursive
loop exposed, which led to infinite inlinings.  Doesn't bite much, but
was obviously wrong.

I've change the "scoring order" for loop breakers, which could possibly
have a performance impact on other programs.  A full nofib run exposed
a 0.00% change in allocation in any nofib program, so I don't think it's
likely, but keep an eye out.

First, cycles can only start of with registers and their destination
must involve a register location. This is because memory locations are
allocated exclusively for a virtual register and hence can never cause
a conflict in the assignment, hence need no fixup code. Therefore, we
only have to deal with InReg -> InReg, or InReg -> InReg/InMem
movements.  

The strategy is to take the first cycle element, which is guaranteed
to start with a register, spill it to a fresh memory location, compute
the fixup for the rest, and restore from the spill slot to its
destinations. The "rest" will degenerate into an acyclic scc, so we do
not need take care of the empty list case in CyclicScc. 
 ***END OF DESCRIPTION***

Place the long patch description above the ***END OF DESCRIPTION*** marker.
The first line of this file will be the patch name.


This patch contains the following changes:

M ./compiler/nativeGen/RegisterAlloc.hs -6 +27

Consider
  lvl = Just True

  foo :: Maybe Bool -> Int -> Int
  foo (Just True) i = i
  foo _           i = foo lvl i

SpecConstr should specialise foo, but it wasn't doing so (spotted
by Roman).

Reason: lvl's unfolding wasn't in the cloned version of lvl.
Solution: extend the value environment to record top-level bindings too

At the same time I made it work if 'lvl' is a lambda, in which case it
is again worth specialisg.  This meant renaming ConEnv to ValueEnv,
and adding a case for 'LambdaVal'.

(To make specialisation on lambdas work properly, we have to do lambda
lifting as well, but this gets part of the way, and fixes a bug too.)

It makes *sense* for a foreign import to have a zero-sized return, thus

  foreign import ccall foo :: Int -> State# RealWorld

but it's not clear that it's useful, and it requires some back-end (a
Hint for void types) to make it go right through. It's not clear that
we really want this facility, so rather than fixing the code
generator, I'm just making the construct illegal for now.

Trac #1581 was doing too much filtering; it even filtered out intances 
defined in this very module!  The new rule shows more instances, but
hopefully not to many.

Furthermore I have moved the filtering out of TcRnDriver (where it does
not belong) to InteractiveEval. And I've added a note to the documentation.

So we will inherit default values for any new flags that get added,
so things should not break if new flags are added.

Defaulting makes compilation of multiple modules more complicated (re: #1405)
Although it was all locally within functions, not because of the module
monomorphism-restriction... but it's better to be clear what's meant, anyway.
I changed some that were defaulting to Integer, to explicit Int, where Int
seemed appropriate rather than Integer.

Print the list of strings that are accepted in a LANGUAGE pragma,
or as a -XFoo flag. (No can be prepended to any of the strings).

-fparr did exist before, it just wasn't documented.

Now we only allow -XFooBar syntax, not alternate case, hyphens or -f.
There are some deprecated -f flags accordingly.