GitLab

PowerPC: for ccalls, use the correct minimum size (32 bytes) for the
parameter area

Fix a type and a bug for PowerPC.

make it compile again (x86)

The Native Code Generator for PowerPC.
Still to be done:
*) Proper support of Floats and Doubles
   currently it seems to work, but it's just guesswork.
*) Some missing operations, only needed for -O, AFAICT.
*) Mach-O dynamic linker stub generation.
   (can't import foreign functions from dynamic libraries,
   and it might fail for big programs)

Native code gen primpops (courtesy Julian)

Housekeeping:

  - The main goal is to remove dependencies on hslibs for a
    bootstrapped compiler, leaving only a requirement that the
    packages base, haskell98 and readline are built in stage 1 in
    order to bootstrap.  We're almost there: Posix is still required
    for signal handling, but all other dependencies on hslibs are now
    gone.

    Uses of Addr and ByteArray/MutableByteArray array are all gone
    from the compiler.  PrimPacked defines the Ptr type for GHC 4.08
    (which didn't have it), and it defines simple BA and MBA types to
    replace uses of ByteArray and MutableByteArray respectively.

  - Clean up import lists.  HsVersions.h now defines macros for some
    modules which have moved between GHC versions.  eg. one now
    imports 'GLAEXTS' to get at unboxed types and primops in the
    compiler.

    Many import lists have been sorted as per the recommendations in
    the new style guidelines in the commentary.

I've built the compiler with GHC 4.08.2, 5.00.2, 5.02.3, 5.04 and
itself, and everything still works here.  Doubtless I've got something
wrong, though.

PrimRep Cleanup

   - Remove all PrimReps which were just different flavours of
     PtrRep.  Now, everything which is a pointer to a closure of
     some kind is always a PtrRep.

   - Three of the deleted PrimReps, namely ArrayRep, ByteArrayRep,
     and ForeignObj rep, had a subtle reason for their existence:
     the abstract C pretty-printer(!) used them to decide whether
     to apply a shim to an outgoing C-call argument: a ByteArrayRep
     argument would be adjusted to point past the object header,
     for example.

     I've changed this to happen in a much more reasonable and
     obvious way: there are now explict macros in AbsCSyn to do the
     adjustment, and the code generator makes calls to these as
     necessary.  Slightly less hackery is necessary in the NCG as
     a result.

Sparc NCG fix from Sven Panne: 8-byte align the stack ptr when doing a ccall.

Teach code gen about some extra no-ops

ptext => ftext

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.

Back out previous fix, it was wrong.

Fix a bug in the native code generator's handling of floating-point
arguments to ccalls: it wasn't correctly promoting float arguments to
doubles.  Amazingly this has gone undetected for quite a while.

Fixes bug #523996.

Also implement MO_32U_to_8U for sparc.  sigh.

Implement missing MachOp, MO_8U_to_32U, for sparc.  (duh!)

Fix debug build.

x86 only: remove special ccall support for calling PerformGC_wrapper
using dodgy-looking calling convention.  PerformGC_wrapper was last
seen alive in GHC 3.X, AFAIK.

sparc NCG fixes for f-i-dynamic.

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

wibble

Generate floating-point comparisons on x86 which deal with NaNs in what
I assume is an IEEE854 compliant fashion.  For
   == >= > <= <
if either arg is a NaN, produce False, and for
   /=
if either arg is a NaN, produce True.

This is the behaviour that gcc has, by default.

Requires some ultramagical x86 code frags to be emitted.  A big comment
in PprMach explains how it works.

Fix various bugs in the implementation of subIntC and mulMayOflo.

Redo translation of array indexing primops in order to insert 8 <-> 32
bit casts when dealing with Char arrays.  Also facilitate future removal
of CMem and MO_{Read,Write}OSBI.

In the process, notice and fix a large bogon in x86/sparc implementation
of signed and unsigned integer widening.

Sparc NCG changes to track recent mulIntC# changes.  The Prelude
can now finally be compiled with the sparc NCG.

Also (incidentally) emit sparc integer multiply insns directly
rather than calling a helper routine.  Most sparcs should implement
them by now :)

Get rid of multiple-result MachOps (MO_NatS_AddC, MO_NatS_SubC,
MO_NatS_MulC) which implement {add,sub,mul}IntC#.  Supporting gunk
in the NCG disappears as a result.

Instead:

* {add,sub}IntC# are translated out during abstract C simplification,
  turning into the xor-xor-invert-and-shift sequence previously defined
  in PrimOps.h.

* mulIntC# is more difficult to get rid of portably.  Instead we have
  a new single-result PrimOp, mulIntMayOflo, with corresponding MachOp
  MO_NatS_MulMayOflo.  This tells you whether a W x W -> W signed
  multiply might overflow, where W is the word size.  When W=32, is
  implemented by computing a 2W-long result.  When W=64, we use the
  previous approximation.

PrelNum.lhs' implementation of timesInteger changes slightly, to use
the new PrimOp.

Make the sparc native code generator work again after recent
primop hackery.

* Track the change from PrimOp to MachOp at the Stix level.

* Teach the sparc insn selector how to generate 64-bit code.

* Fix various bogons in sparc {Int,Double,Float} <-> {Int,Double,Float}
  conversions which only happened to generate correct code by
  accident, so far.

* Synthesise BaseReg from &MainCapability.r on archs which do not
  have BaseReg in a regiser (eg sparc :)

At the moment {add,sub,mul}Int# are not implemented.  To be fixed.

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.

Make it compile -DDEBUG.

--------------------------------------------
        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.

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.

merge from stable, revs:

  1.74.4.1  +12 -11    fptools/ghc/compiler/nativeGen/MachCode.lhs
  1.30.4.1  +23 -0     fptools/ghc/compiler/nativeGen/Stix.lhs
  1.70.4.1  +2 -5      fptools/ghc/compiler/nativeGen/StixPrim.lhs

  Route all NCG panics to do with missing primop implementations and any
  other panic which could be caused by compiling legitimate sources
  through the function Stix.ncgPrimopMoan.  This emits a helpful message
  explaining what has happened, advises the use of -fvia-C as a
  workaround, and says please mail us.

Deleted HsVersions.h #defines that were now past their use-by-dates; in
particular, make the assumption that a post-Haskell 1.4 compiler is now
used to compile ghc/compiler/

Hanging on to those FastString #defines is probably not worth it any longer,
either, but I punted on making that (much bigger) change.

import CLabe (isAsmTemp) for sparc/alpha (I guess someone removed the
import after a warning from -fwarn-unused-imports, so I've put the
import inside the relevant #ifdef this time).

-------------------------------
	Code generation and SRT hygiene
	-------------------------------

This is a big tidy up commit.  I don't think it breaks anything,
but it certainly makes the code clearer (to me).

I'm not certain that you can use it without sucking in my other
big commit... they come from the same tree.


Core-to-STG, live variables and Static Reference Tables (SRTs)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I did a big tidy-up of the live-variable computation in CoreToStg.
The key idea is that the live variables consist of two parts:
	dynamic live vars
	static live vars (CAFs)

These two always travel round together, but they were always
treated separately by the code until now. Now it's a new data type:

type LiveInfo = (StgLiveVars, 	-- Dynamic live variables;
				-- i.e. ones with a nested (non-top-level) binding
		 CafSet)	-- Static live variables;
				-- i.e. top-level variables that are CAFs or refer to them

There's lots of documentation in CoreToStg.

Code generation
~~~~~~~~~~~~~~~
Arising from this, I found that SRT labels were stored in
a LambdaFormInfo during code generation, whereas they *ought*
to be in the ClosureInfo (which in turn contains a LambdaFormInfo).

This led to lots of changes in ClosureInfo, and I took the opportunity
to make it into a labelled record.

Similarly, I made the data type in AbstractC a bit more explicit:

  -- C_SRT is what StgSyn.SRT gets translated to...
  -- we add a label for the table, and expect only the 'offset/length' form

data C_SRT = NoC_SRT
	   | C_SRT CLabel !Int{-offset-} !Int{-length-}

(Previously there were bottoms lying around.)

How I spent my summer vacation.

Primops
-------

The format of the primops.txt.pp file has been enhanced to allow
(latex-style) primop descriptions to be included.  There is a new flag
to genprimopcode that generates documentation including these
descriptions. A first cut at descriptions of the more interesting
primops has been made, and the file has been reordered a bit.

31-bit words
------------

The front end now can cope with the possibility of 31-bit (or even 30-bit)
Int# and Word# types.  The only current use of this is to generate
external .core files that can be translated into OCAML source files
(OCAML uses a one-bit tag to distinguish integers from pointers).
The only way to get this right now is by hand-defining the preprocessor
symbol WORD_SIZE_IN_BITS, which is normally set automatically from
the familiar WORD_SIZE_IN_BYTES.

Just in case 31-bit words are used, we now have Int32# and Word32# primitive types
and an associated family of operators, paralleling the existing 64-bit
stuff.  Of course, none of the operators actually need to be implemented
in the absence of a 31-bit backend.
There has also been some minor re-jigging of the 32 vs. 64 bit stuff.
See the description at the top of primops.txt.pp file for more details.
Note that, for the first time, the *type* of a primop can now depend
on the target word size.

Also, the family of primops intToInt8#, intToInt16#, etc.
have been renamed narrow8Int#, narrow16Int#, etc., to emphasize
that they work on Int#'s and don't actually convert between types.

Addresses
---------

As another part of coping with the possibility of 31-bit ints,
the addr2Int# and int2Addr# primops are now thoroughly deprecated
(and not even defined in the 31-bit case) and all uses
of them have been removed except from the (deprecated) module
hslibs/lang/Addr

Addr# should now be treated as a proper abstract type, and has these suitable operators:

nullAddr# : Int# -> Addr# (ignores its argument; nullary primops cause problems at various places)
plusAddr# :  Addr# -> Int# -> Addr#
minusAddr : Addr# -> Addr# -> Int#
remAddr# : Addr# -> Int# -> Int#

Obviously, these don't allow completely arbitrary offsets if 31-bit ints are
in use, but they should do for all practical purposes.

It is also still possible to generate an address constant, and there is a built-in rule
that makes use of this to remove the nullAddr# calls.

Misc
----
There is a new compile flag -fno-code that causes GHC to quit after generating .hi files
and .core files (if requested) but before generating STG.

Z-encoded names for tuples have been rationalized; e.g.,
Z3H now means an unboxed 3-tuple, rather than an unboxed
tuple with 3 commas (i.e., a 4-tuple)!

Removed misc. litlits in hslibs/lang

Misc. small changes to external core format.  The external core description
has also been substantially updated, and incorporates the automatically-generated
primop documentation; its in the repository at /papers/ext-core/core.tex.

A little make-system addition to allow passing CPP options to compiler and
library builds.

Add comments

Fix small callconv-related import mismatches etc.

-------------------------------------------
	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.

merge rev 1.69.2.1, which was:
Remove x86-specific implementation of {intToInt,wordToWord}{8,16,32}#
primops, and replace them with platform-independent versions expressed
purely in Stix terms.

* Add {intToInt,wordToWord}{8,16,32}# primops. WARNING: Not implemented
  in ncg for Alpha and Sparc. But -O -fasm is not going to go far anyway
  because of other omissions.

* Have full repertoire of 8,16,32-bit signed and unsigned MachMisc.Size
  values. Again only x86 is fully supported. They are used for
  {index,read,write}{Int,Word}{8,16,32}{OffAddr,Array}# and
  {intToInt,wordToWord}{8,16,32}# primops.

* Have full repertoire of
  {index,read,write}\
  {Char,WideChar,Int,Word,Addr,Float,Double,StablePtr,\
   {Int,Word}{8,16,32,64}}\
  {OffAddr,Array} primops and appropriate instances.
  There were various omissions in various places.

* Add {plus,minus,times}Word# primops to avoid so many Word# <-> Int#
  coercions.

* Rewrite modules PrelWord and PrelInt almost from scratch.

* Simplify fromInteger and realToFrac rules. For each of
  {Int,Word}{8,16,32} there is just a pair of fromInteger rules
  replacing the source or target type with Int or Word. For
  {Int,Word,Int64,Word64} there are rules from any to any.
  Don't include rules which are derivable from inlining anyway,
  e.g. those mentioning Integer. Old explicit coercions are simply
  defined as appropriately typed fromInteger.

* Various old coercion functions marked as deprecated.

* Add instance Bits Int, and
  instance {Show,Num,Real,Enum,Integral,Bounded,Ix,Read,Bits} Word.

* Coercions to sized integer types consistently behave as cutting the
  right amount of bits from the infinite two-complement representation.
  For example (fromIntegral (-1 :: Int8) :: Word64) == maxBound.

* ghc/tests/numeric/should_run/arith011 tests {Int,Word}64 and instance
  Bits Int, and does not try to use overflowing toEnum. arith011.stdout
  is not updated yet because of a problem I will tell about soon.

* Move fromInteger and realToFrac from Prelude to PrelReal.
  Move fromInt from PrelNum to PrelReal and define as fromInteger.
  Define toInt as fromInteger. fromInteger is the place to write
  integer conversion rules for.

* Remove ArrayBase.newInitialisedArray, use default definition of
  newArray instead.

* Bugs fixed:
  - {quot,rem}Word# primop attributes.
  - integerToInt64# for small negative values.
  - {min,max}Bound::Int on 64-bit platforms.
  - iShiftRL64#.
  - Various Bits instances.

* Polishing:
  - Use 'ppr' instead of 'pprPrimOp' and 'text . showPrimRep'.
  - PrimRep.{primRepString,showPrimRepToUser} removed.
  - MachMisc.sizeOf returns Int instead of Integer.
  - Some eta reduction, parens, spacing, and reordering cleanups -
    sorry, couldn't resist.

* Questions:
  - Should iShiftRL and iShiftRL64 be removed? IMHO they should,
    s/iShiftRA/iShiftR/, s/shiftRL/shiftR/. The behaviour on shifting
    is a property of the signedness of the type, not the operation!
    I haven't done this change.