Simon,
Possibly, yes. IIRC, -O3 was mainly to get some loop unrolling. This is a performance-critical part of the system though, and when making any changes we like to measure things to make sure we haven't pessimised performance.
I will try to test it both ways, then. Also, -optc-O3 is turned on even for debug builds since GC_HC_OPTS is set unconditionally. I could change it to: ifneq (,$(findstring $(SRC_HC_OPTS), -DDEBUG)) GC_HC_OPTS += -optc-O3 endif
(3) I have been looking at how to implement a dual-constructor-in-a- pointer for Integer (i.e., merge constructors of small Integers and big Integers into the Int#). Would that solution be workable or might it break current Haskell programs? Just a thought.
Which representation in particular are you talking about here?
I was talking about the definition of Integer in packages/base/GHC/ Num.lhs particularly the implementation in PrimOps.cmm, which returns Integers as: /* returns (# size :: Int#, data :: ByteArray# #) */ RET_NP(s,p); If the ByteArray were indicated through a pointer, the representation in Haskell would be J# IntegerT# {- new type, depending on pointer size, either holding 30 or 62 bits of precision -} and a Cmm procedure returning an Integer would be: RET_NP(p); I hope this doesn't confuse you. Best regards, Peter