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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
