unboxed types

[Simon Marlow]

Isaac Dupree wrote:

> nativeGen/MachRegs uses unboxed tuples to contain FastInts, which may be 
> unboxed.
> 
> nativeGen/AsmCodeGen, nativeGen/RegAllocLinear, and utils/State each use 
> unboxed tuples in return values of newtypes that are declared Monads -- 
> efficiency of the tuple is the only excuse (not even efficiency of what 
> it contains), and I may test how they are with boxed tuples.  On the 
> other hand, as far as I can tell, CmmOptM and RegM are really just state 
> monads that can and should use utils/State.  No, actually CmmOptM is a 
> State/Reader monad... which it's not quite as obvious what to do with.
> 
> utf8DecodeChar# in utils/Encoding (defined) and utils/StringBuffer 
> (used) has unboxed tuple that contains FastTypes (well, unboxed types, 
> but I think I'm going to make a FastChar and FastPtr to allow conversion 
> of this kind of code)
> 
> The comments make clear that some of these places *are* hotspots (at 
> least believed at the time of writing) (nativeGen/MachRegs' 
> trivColorable, and utf8DecodeChar -- the monads' unboxed tuples aren't 
> mentioned)
> 
> The rest of the unboxed-tuple uses are either not part of stage1 code, 
> or refer to actual GHC-specific uses such as using the newtype IO 
> constructor.
> 
> Given these few places, the limitations of past GHCs, and the desire to 
> have unoptimized GHC be a decent speed, I think UTopen and UTclose 
> macros are probably the best solution.

Agreed.  It's very difficult to test whether a particular change degrades 
performance, as it might only do so on certain examples.

The best approach is to try to isolate the compiler-specific code as much 
as possible - for example having compiler-specific implementations of 
utils/State.

   (opinions?)  Given those macros,
> and my type-class-extension-removal patchset, a GHC stage1 is in sight 
> (needs a little more hacking and hack-cleanup on my part before 
> submitting, maybe 1 day) that "only" uses CPP, ForeignFunctionInterface, 
> PatternGuards and Rank2Types; plus MagicHash, UnboxedTuples and 
> importing GHC.*, when __GLASGOW_HASKELL__ is defined.  It might be 
> possible that the four modules that use Rank2Types could be refactored 
> not to, but that would be no use because GHC also uses module import 
> cycles, which neither hugs nor nyhc support.
> 
> extension matrix, am I right? (did the tabs work to format it?)

no :)

> hmm... maybe I'll move some of these observations to the Trac ticket 
> http://hackage.haskell.org/trac/ghc/ticket/1405 when I'm more organized 
> with my patches.

Good plan.

Cheers,
	Simon