GitLab

update aLL_NON_PTRS for the new RET_DYN stack frame layout.

Merge the eval-apply-branch on to the HEAD
------------------------------------------

This is a change to GHC's evaluation model in order to ultimately make
GHC more portable and to reduce complexity in some areas.

At some point we'll update the commentary to describe the new state of
the RTS.  Pending that, the highlights of this change are:

  - No more Su.  The Su register is gone, update frames are one
    word smaller.

  - Slow-entry points and arg checks are gone.  Unknown function calls
    are handled by automatically-generated RTS entry points (AutoApply.hc,
    generated by the program in utils/genapply).

  - The stack layout is stricter: there are no "pending arguments" on
    the stack any more, the stack is always strictly a sequence of
    stack frames.

    This means that there's no need for LOOKS_LIKE_GHC_INFO() or
    LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
    how to find the boundary between the text and data segments (BIG WIN!).

  - A couple of nasty hacks in the mangler caused by the neet to
    identify closure ptrs vs. info tables have gone away.

  - Info tables are a bit more complicated.  See InfoTables.h for the
    details.

  - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
    in GHCi which affected primitives and unboxed tuples are now
    fixed.

  - Binary sizes are reduced by about 7% on x86.  Performance is roughly
    similar, some programs get faster while some get slower.  I've seen
    GHCi perform worse on some examples, but haven't investigated
    further yet (GHCi performance *should* be about the same or better
    in theory).

  - Internally the code generator is rather better organised.  I've moved
    info-table generation from the NCG into the main codeGen where it is
    shared with the C back-end; info tables are now emitted as arrays
    of words in both back-ends.  The NCG is one step closer to being able
    to support profiling.

This has all been fairly thoroughly tested, but no doubt I've messed
up the commit in some way.

FastString cleanup, stage 1.

The FastString type is no longer a mixture of hashed strings and
literal strings, it contains hashed strings only with O(1) comparison
(except for UnicodeStr, but that will also go away in due course).  To
create a literal instance of FastString, use FSLIT("..").

By far the most common use of the old literal version of FastString
was in the pattern

	  ptext SLIT("...")

this combination still works, although it doesn't go via FastString
any more.  The next stage will be to remove the need to use this
special combination at all, using a RULE.

To convert a FastString into an SDoc, now use 'ftext' instead of
'ptext'.

I've also removed all the FAST_STRING related macros from HsVersions.h
except for SLIT and FSLIT, just use the relevant functions from
FastString instead.

Teach the NCG how to do f-i-dynamic.  Nothing unexpected.
sparc-side now needs fixing.

Add just enough infrastructure to the NCG that it can deal with simple 64-bit
code on 32-bit platforms.  Main changes are:

* Addition of a simple 64-bit instruction selection fn iselExpr64 to MachCode.
  This generates code for a 64-bit value and places the results into two
  virtual registers, related thusly:

* Add a new type VRegUnique, which is used to label Stix virtual registers.
  This type used to be a plain Unique, but that forces the assumption that
  each Abstract-C level C temporary corresponds to exactly one Stix virtual
  register, which is untrue when the C temporary is 64-bit sized on a
  32-bit machine.  In the new scheme, the Unique for the C temporary can
  turn into two related VRegUniques, related by having the same embedded
  unique.

* Made a start on 'target metrics' by adding ncg_target_is_32bits to the
  end of Stix.lhs.

* Cleaned up numerous other gruesomenesses in the NCG which never came
  to light before now.   Got rid of MachMisc.sizeOf, which doesn't make
  sense in a 64-bit setting, and replaced it by calls to
  PrimRep.getPrimRepArrayElemSize, which, as far as I'm concerned, is the
  definitive answer to the questio `How Big Is This PrimRep Really?'

Result: on x86-linux, at least, you can now compile the Entire Prelude
with -fasm!  At this stage I cannot claim that the resulting code is
correct, but it's a start.

--------------------------------------------
        Translate out PrimOps at the AbstractC level
        --------------------------------------------

This is the first in what might be a series of changes intended
to make GHC less dependent on its C back end.  The main change is
to translate PrimOps into vanilla abstract C inside the compiler,
rather than having to duplicate that work in each code generation
route.  The main changes are:

* A new type, MachOp, in compiler/absCSyn/MachOp.hs.  A MachOp
  is a primitive operation which we can reasonably expect the
  native code generators to implement.  The set is quite small
  and unlikely to change much, if at all.

* Translations from PrimOps to MachOps, at the end of
  absCSyn/AbsCUtils.  This should perhaps be moved to a different
  module, but it is hard to see how to do this without creating
  a circular dep between it and AbsCUtils.

* The x86 insn selector has been updated to track these changes.  The
  sparc insn selector remains to be done.

As a result of this, it is possible to compile much more code via the
NCG than before.  Almost all the Prelude can be compiled with it.
Currently it does not know how to do 64-bit code generation.  Once
this is fixed, the entire Prelude should be compilable that way.

I also took the opportunity to clean up the NCG infrastructure.
The old Stix data type has been split into StixStmt (statements)
and StixExpr (now denoting values only).  This removes a class
of impossible constructions and clarifies the NCG.

Still to do, in no particular order:

* String and literal lifting, currently done in the NCG at the top
  of nativeGen/MachCode, should be done in the AbstractC flattener,
  for the benefit of all targets.

* Further cleaning up of Stix assignments.

* Remove word-size dependency from Abstract C.  (should be easy).

* Translate out MagicIds in the AbsC -> Stix translation, not
  in the Stix constant folder. (!)

Testsuite failures caused by this:

* memo001 - fails (segfaults) for some unknown reason now.
* arith003 - wrong answer in gcdInt boundary cases.
* arith011 - wrong answer for shifts >= word size.
* cg044 - wrong answer for some FP boundary cases.

These should be fixed, but I don't think they are mission-critical for
anyone.

Tidy up imports

Updates to the native code generator following the changes to fix the
large block allocation bug, and changes to use the new
function-address cache in the register table to reduce code size.

Also: I changed the pretty-printing machinery for assembly code to use
Pretty rather than Outputable, since we don't make use of the styles
and it should improve performance.  Perhaps the same should be done
for abstract C.

Fix a difference between the NCG implementation of the UPD_CAF() macro
and the C version.  I think the C version was changed recently but the
NCG version never caught up.  Fixes a crash in GHCi with NCG compiled
code.

-------------------------------------------
	Towards generalising 'foreign' declarations
	-------------------------------------------

This is a first step towards generalising 'foreign' declarations to
handle langauges other than C.  Quite a lot of files are touched,
but nothing has really changed.  Everything should work exactly as
before.

	But please be on your guard for ccall-related bugs.

Main things

Basic data types: ForeignCall.lhs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Remove absCSyn/CallConv.lhs

* Add prelude/ForeignCall.lhs.  This defines the ForeignCall
  type and its variants

* Define ForeignCall.Safety to say whether a call is unsafe
  or not (was just a boolean).  Lots of consequential chuffing.

* Remove all CCall stuff from PrimOp, and put it in ForeignCall


Take CCallOp out of the PrimOp type (where it was always a glitch)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Add IdInfo.FCallId variant to the type IdInfo.GlobalIdDetails,
	along with predicates Id.isFCallId, Id.isFCallId_maybe

* Add StgSyn.StgOp, to sum PrimOp with FCallOp, because it
  *is* useful to sum them together in Stg and AbsC land.  If
  nothing else, it minimises changes.


Also generally rename "CCall" stuff to "FCall" where it's generic
to all foreign calls.

Dealing with instance-decl imports; and removing unnecessary imports

Make the register allocator deal properly with switch tables.
Previously, it didn't calculate the correct flow edges away from the
indirect jump (in fact it didn't reckon there were any flow edges
leaving it :) which makes a nonsense of the live variable analysis in
the branches.

A jump insn can now optionally be annotated with a list of destination
labels, and if so, the register allocator creates flow edges to all of
them.

Jump tables are now re-enabled.  They remain disabled for 4.08.1,
since we aren't fixing the problem properly on that branch.

I assume this problem wasn't exposed by the old register allocator
because of the live-range-approximation hacks used in it.  Since it
was undocumented, we'll never know.

Sparc builds will now break until I fix them.

This commit completely re-does the kind-inference mechanism.
Previously it was inter-wound with type inference, but that was
always hard to understand, and it finally broke when we started
checking for ambiguity when type-checking a type signature (details
irrelevant).

So now kind inference is more clearly separated, so that it never
takes place at the same time as type inference.  The biggest change
is in TcTyClsDecls, which does the kind inference for a group of
type and class declarations.  It now contains comments to explain
how it all works.

There are also comments in TypeRep which describes the slightly
tricky way in which we deal with the fact that kind 'type' (written
'*') actually has 'boxed type' and 'unboxed type' as sub-kinds.
The whole thing is a bit of a hack, because we don't really have 
sub-kinding, but it's less of a hack than before.

A lot of general tidying up happened at the same time.
In particular, I removed some dead code here and there

remove unused imports

Teach the NCG about the dereferencing and naming conventions to be
used when compiling for a DLLised world.  Some cleanups on the way
too.  The scheme is that

* All CLabels which are in different DLLs from the current module
  will, via the renamer, already be such that labelDynamic returns
  True for them.

* Redo the StixPrim/StixMacro stuff so that all references to symbols
  in the RTS are via CLabels.  That means that the usual labelDynamic
  story can be used.

* When a label is printed in PprMach, labelDynamic is consulted, to
  generate the __imp_ prefix if necessary.

* In MachCode.stmt2Instrs, selectively ask derefDLL to walk trees
  before code generation and insert deferencing code around other-DLL
  symbols.

* When generating Stix for SRTs, add 1 to other-DLL refs.

* When generating static closures, insert a zero word before
  the _closure label.

I lied earlier.  _ccall_GC_ should work now.

Clean up the module initialisation stuff a bit, and add support for
module initialisation blocks in the native code generator.

Many changes to improve the quality and correctness of generated code,
both for x86 and all-platforms.  The intent is that the x86 NCG will
now be good enough for general use.

-- Add an almost-trivial Stix (generic) peephole optimiser, whose sole
   purpose is elide assignments to temporaries used only once, in the
   very next tree.  This generates substantially better code for
   conditionals on all platforms.  Enhance Stix constant folding to
   take advantage of the inlining.

   The inlining presents subsequent insn selection phases with more
   complex trees than would have previously been used to.  This has
   shown up several bugs in the x86 insn selectors, now fixed.
   (assumptions that data size is Word, when could be Byte,
    assumptions that an operand will always be in a temp reg, etc)

-- x86: Use the FLDZ and FLD1 insns.

-- x86: spill FP registers with 80-bit loads/stores so that
   Intel's extra 16 bits of accuracy are not lost.  If this isn't
   done, FP spills are not suitably transparent.  Increase the
   number of spill words available to 2048.

-- x86: give the register allocator more flexibility in choosing
   spill temporaries.

-- x86, RegAllocInfo.regUsage: fix error for GST, and rewrite to
   make it clearer.

-- Correctly track movements in the C stack pointer, and generate
   correct spill code for archs which spill against the stack pointer
   even when the stack pointer moves.  Redo the x86 ccall mechanism
   to push args on the C stack in the normal way.  Rather than have
   the spiller have to analyse code sequences to determine the current
   stack offset, the insn selectors communicate the current offset
   whenever it changes by inserting a DELTA pseudo-insn.  Then the
   spiller only has to spot DELTAs.

   This means having a new native-code-generator monad (Stix.NatM)
   which carries both a UniqSupply and the current stack offset.

-- Remove the asmPar/asmSeq ways of grouping insns together.
   In the presence of fixed registers, it is hard to demonstrate
   that insn selectors using asmPar always give correct code, and
   the extra complication doesn't help any.

   Also, directly construct code sequences using tree-based ordered
   lists (utils/OrdList.lhs) for linear-time appends, rather than
   the bizarrely complex method using fns and fn composition.

-- Inline some hcats in printing of x86 address modes.

-- Document more of the hidden assumptions which insn selection relies
   on, particular wrt addressing modes.

-- Cosmetic changes in register allocator.

-- Implement macro HP_GEN_SEQ_NP.

-- MachCode(trivialCode, x86): because one of the operands is also
   the destination (on this 2-address arch), it's invalid to sequence
   the code to compute the operands using asmParThen [code1, code2].
   since the order of assignments matters.  Fixed.

Implement the HP_CHK_GEN macro.  As a result, teach mkNativeHdr et al
about R9 and R10.

StixPrim.amodeToStix case CMacroExpr: handle UPD_FRAME_UPDATEE
StixMacro.macroCode: handle UPDATE_SU_FROM_UPD_FRAME

macroCode: implement PUSH_SEQ_FRAME

checkCode: handle HP_CHK_UT_ALT.

Merged GUM-4-04 branch into the main trunk. In particular merged GUM and
SMP code. Most of the GranSim code in GUM-4-04 still has to be carried over.

Some native codegen updates.

Move 4.01 onto the main trunk.

StCall now takes extra callconv arg; StixPrim.primCode doesn't flush stdout and stderr anymore (it's done in the .hc code)

The Great Multi-Parameter Type Classes Merge.

Notes from Simon (abridged):

* Multi-parameter type classes are fully implemented.
* Error messages from the type checker should be noticeably improved
* Warnings for unused bindings (-fwarn-unused-names)
* many other minor bug fixes.

Internally there are the following changes

* Removal of Haskell 1.2 compatibility.
* Dramatic clean-up of the PprStyle stuff.
* The type Type has been substantially changed.
* The dictionary for each class is represented by a new
  data type for that purpose, rather than by a tuple.

import MachRegs unconditionally

updated imports

2.04 changes

SLPJ new renamer and lots more

SLPJ 1.3 changes through 96/06/25

SLPJ changes to 960611

SLPJ changes through 960604

Add SLPJ/WDP 1.3 changes through 960404

simonpj/sansom/partain/dnt 1.3 compiler stuff through 96/03/18

Initial revision