Opened 13 years ago

Closed 4 years ago

Last modified 4 years ago

#1405 closed task (wontfix)

Make ghc (stage1) be compilable by non-GHC

Reported by: Isaac Dupree Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.6.1
Keywords: Cc: pho@…, slyfox@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by Isaac Dupree)

This depends a bit on the existence of a good-enough non-GHC compiler. Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet. Also pattern guards might need to be implemented in that compiler. Maybe for testing, a ghc that doesn't define GLASGOW_HASKELL (and doesn't use ghc-specific flags ?? possibly a wrapper script of some sort) could be used too.

See ... GHC also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that everyone provides, but would still be good to document.

I'm working on this now, we'll see how far I get --Isaac

Change History (22)

comment:1 Changed 13 years ago by Isaac Dupree

Also grepping the source for GLASGOW_HASKELL finds many things that need examining. Mostly it is "#if"s for compatibility with old versions of libraries that old versions of GHC have; for non-GHC compilers I think the best thing to do with these is to make sure it assumes the latest version of the libraries (old versions of ghc need to be able to compile new ones for a special reason, and the older versions also had more difficulty having upgradeable packages)

comment:2 Changed 13 years ago by Isaac Dupree

Description: modified (diff)

comment:3 Changed 13 years ago by Isaac Dupree

Hmm, looking again, it does look like GHC's code sometimes uses unboxed stuff and imports GHC.stuff. Some of the places at least, it seems there's really no excuse for doing so... I can change those (at least if I feel sure there are no performance regressions thereby).

comment:4 Changed 13 years ago by simonpj

The other thing to watch out for is that we keep GHC in a state in which it can be compiled by several earlier versions of GHC. I forget what our current earlier-version threshold is (Simon M would know), but in doing your refactoring please be careful to maintain this property. We don't want to pull up the ladder after ourselvese too quickly!


comment:5 Changed 13 years ago by Isaac Dupree

Yes, certainly, I think it's ghc-5.04 currently. Is there an easy way to get a copy of that version of ghc (or other versions between that and the current) to test with? Or should I just rely on my intuition while watching for buildbots breaking that use old versions of ghc?

I think it's okay if GHC is merely slower when compiled with older versions of GHC (since normally you'll be using recent GHC for development, and stage2, anyway), for example if older versions of GHC optimized worse or didn't implement UNPACK pragma...

comment:6 Changed 13 years ago by igloo

We abandoned 5.04 support recently as the differences in its hierarchical libraries compared to 6.x were causing too much pain. I think any 6.x is supposed to still work, though.

Bindists are the simplest way of getting older versions, but you might have problems due to them being compiled against older libraries. If it proves tricky then just keeping an eye on the nightly builds is the way to go.

comment:7 Changed 13 years ago by Isaac Dupree

OK, it's now 6.0 or greater (according to ). Is it preferred, discouraged or neither, to remove #if __GLASGOW_HASKELL__ > 5.04 sorts of checks in the code now?

comment:8 Changed 13 years ago by igloo

Yup, please do remove any such checks.

comment:9 Changed 13 years ago by Isaac Dupree

Should such checks for really old ghc also be removed in the various ghc/utils programs?

comment:10 Changed 13 years ago by igloo

Support for building with old GHCs, yes. Support for things like looking at the output of old GHCs, possibly not.

comment:11 Changed 12 years ago by Isaac Dupree

random notes:

unsafeCoerce# appears to be only used by ghci and template-haskell (i.e. stage2). It would still be nice to use the Unsafe.Coerce "unsafeCoerce" name (IMHO).

'.#' and 'import.*GHC' are good things to grep for to find non-portable code (although especially the first one will find lots of false positives - the . weeds out preprocessor commands that begin with # at the beginning of lines)

comment:12 Changed 12 years ago by Isaac Dupree

I made FiniteMap use {-# UNPACK #-} !Int instead of Int#. Probably it would be better to change to FastInt (which is good for when GHC compiles itself without optimizations).

Thoughts about FastInt and unboxing: A compiler that doesn't have unboxed types could represent them like newtype !FastInt = I__ Int. That ! somewhere indicates to the compiler that wherever this type is used, it is used strictly: with the same restrictions as unboxed types, as if it were !Int everywhere: in data declarations, in function arguments as if the !Int -> x syntax were implemented (only, clearer, because there is a clear source-type-level distinction between the strict and non-strict versions). This has a semantic effect in FastInt -> x but no effect in x -> FastInt, I believe. (And many constructions, like (FastInt, x) are not allowed for unboxed types, and FastInt sometimes _is_ unboxed...)

For now, changing to Int or FastInt as appropriate, seems the best course. But I'm busy with school soon so I might not get to it for a while (and I'm sure someone else could do as good a job as me, if they want).

comment:13 Changed 12 years ago by Isaac Dupree

In future we may want to aim for compiling GHC with just the extensions it needs, e.g. stage1 with -XPatternGuards not full -fglasgow-exts (except when compiling with an older GHC that doesn't support -X flags).

comment:14 Changed 12 years ago by Isaac Dupree

now working on hard work portabilizing! Will send some darcs patches soon. The more suspicious things (e.g. messing with unboxing) I will make sure to run through performance-checker first.

I found out that ghc's code uses Rank2Types in a few places, in a way that would require changing code substantively to remove, so I guess GHC will just require that useful extension implemented in compilers that want to build GHC :-) (unless someone is really interested in changing that sometime -- and only n/Yhc which doesn't implement cyclically-importing modules either, doesn't implement Rank2Types, IIRC)

details come later

comment:15 Changed 11 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:16 Changed 11 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:17 Changed 10 years ago by PHO

Cc: pho@… added

comment:18 Changed 10 years ago by slyfox

Cc: slyfox@… added
Type of failure: None/Unknown

comment:19 Changed 5 years ago by thomie

In 206b4dec78250efef3cd927d64dc6cbc54a16c3d/ghc:

lots of portability changes (#1405)

re-recording to avoid new conflicts was too hard, so I just put it
all in one big patch :-(  (besides, some of the changes depended on
each other.)  Here are what the component patches were:

Fri Dec 28 11:02:55 EST 2007  Isaac Dupree <>
  * document BreakArray better

Fri Dec 28 11:39:22 EST 2007  Isaac Dupree <>
  * properly ifdef BreakArray for GHCI

Fri Jan  4 13:50:41 EST 2008  Isaac Dupree <>
  * change ifs on __GLASGOW_HASKELL__ to account for... (#1405)
  for it not being defined. I assume it being undefined implies
  a compiler with relatively modern libraries but without most
  unportable glasgow extensions.

Fri Jan  4 14:21:21 EST 2008  Isaac Dupree <>
  * MyEither-->EitherString to allow Haskell98 instance

Fri Jan  4 16:13:29 EST 2008  Isaac Dupree <>
  * re-portabilize Pretty, and corresponding changes

Fri Jan  4 17:19:55 EST 2008  Isaac Dupree <>
  * Augment FastTypes to be much more complete

Fri Jan  4 20:14:19 EST 2008  Isaac Dupree <>
  * use FastFunctions, cleanup FastString slightly

Fri Jan  4 21:00:22 EST 2008  Isaac Dupree <>
  * Massive de-"#", mostly Int# --> FastInt (#1405)

Fri Jan  4 21:02:49 EST 2008  Isaac Dupree <>
  * miscellaneous unnecessary-extension-removal

Sat Jan  5 19:30:13 EST 2008  Isaac Dupree <>
  * add FastFunctions

comment:20 Changed 4 years ago by thomie

Resolution: wontfix
Status: newclosed

I'm slowly reverting this work. There's no point in pretending GHC can still be compiled by other compilers.

comment:21 Changed 4 years ago by Ben Gamari <ben@…>

In 3452473b/ghc:

Delete FastBool

This reverses some of the work done in Trac #1405, and assumes GHC is
smart enough to do its own unboxing of booleans now.

I would like to do some more performance measurements, but the code
changes can be reviewed already.

Test Plan:
With a perf build:
./inplace/bin/ghc-stage2 nofib/spectral/simple/Main.hs -fforce-recomp
+RTS -t --machine-readable

  [("bytes allocated", "1300744864")
  ,("num_GCs", "302")
  ,("average_bytes_used", "8811118")
  ,("max_bytes_used", "24477464")
  ,("num_byte_usage_samples", "9")
  ,("peak_megabytes_allocated", "64")
  ,("init_cpu_seconds", "0.001")
  ,("init_wall_seconds", "0.001")
  ,("mutator_cpu_seconds", "2.833")
  ,("mutator_wall_seconds", "4.283")
  ,("GC_cpu_seconds", "0.960")
  ,("GC_wall_seconds", "0.961")

  [("bytes allocated", "1301088064")
  ,("num_GCs", "310")
  ,("average_bytes_used", "8820253")
  ,("max_bytes_used", "24539904")
  ,("num_byte_usage_samples", "9")
  ,("peak_megabytes_allocated", "64")
  ,("init_cpu_seconds", "0.001")
  ,("init_wall_seconds", "0.001")
  ,("mutator_cpu_seconds", "2.876")
  ,("mutator_wall_seconds", "4.474")
  ,("GC_cpu_seconds", "0.965")
  ,("GC_wall_seconds", "0.979")

CPU time seems to be up a bit, but I'm not sure. Unfortunately CPU time
measurements are rather noisy.

Reviewers: austin, bgamari, rwbarton

Subscribers: nomeata

Differential Revision:

GHC Trac Issues: #1405

comment:22 Changed 4 years ago by Ben Gamari <ben@…>

In 2f29ebb/ghc:

Refactor: delete most of the module FastTypes

This reverses some of the work done in #1405, and goes back to the
assumption that the bootstrap compiler understands GHC-haskell.

In particular:
  * use MagicHash instead of _ILIT and _CLIT
  * pattern matching on I# if possible, instead of using iUnbox
  * use Int#/Char#/Addr# instead of the following type synonyms:
    - type FastInt   = Int#
    - type FastChar  = Char#
    - type FastPtr a = Addr#
  * inline the following functions:
    - iBox           = I#
    - cBox           = C#
    - fastChr        = chr#
    - fastOrd        = ord#
    - eqFastChar     = eqChar#
    - shiftLFastInt  = uncheckedIShiftL#
    - shiftR_FastInt = uncheckedIShiftRL#
    - shiftRLFastInt = uncheckedIShiftRL#
  * delete the following unused functions:
    - minFastInt
    - maxFastInt
    - uncheckedIShiftRA#
    - castFastPtr
    - panicDocFastInt and pprPanicFastInt
  * rename panicFastInt back to panic#

These functions remain, since they actually do something:
  * iUnbox
  * bitAndFastInt
  * bitOrFastInt

Test Plan: validate

Reviewers: austin, bgamari

Subscribers: rwbarton

Differential Revision:

GHC Trac Issues: #1405
Note: See TracTickets for help on using tickets.