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
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
