#5284: Simplifier performance regression (or infinite loop)
---------------------------------+------------------------------------------
Reporter: simonmar | Owner: igloo
Type: bug | Status: new
Priority: high | Milestone: 7.4.1
Component: Compiler | Version: 7.0.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Compile-time performance bug
---------------------------------+------------------------------------------
Comment(by simonmar):
Simon and I had a chat about the representation of Integer literals today.
Here's our proposed plan, which Ian has agreed to look into implementing.
* small `Integer` literals will continue to be represented by explicit
`S#` constructors in Core
* large `Integer` literals will turn into `mkInteger <len> "<bytes>"#`
where `<bytes>` is the binary representation of the big int (choosing
endianness etc. appropriately to be as close as possible to the GMP
representation), and `<len>` is the number of bytes (multiplied by -1 if
the literal is negative, as in GMP). The implementation of `mkInteger` in
`integer-gmp` creates a `J#`, hopefully with little fuss - just allocating
a `ByteArray#` and copying the bytes. Perhaps some byte-swapping within
each word will be necessary. The point is that this is a very compact
representation of `Integer` literals, that is also amenable to constant
folding.
* To fix #5152, we have a built-in rule for `fromInteger` at `Word64`,
recognising a call to `mkInteger` in its argument (and possibly the other
integral types, replacing the current typechecker magic?)
* We could also add constant folding for large integers by recognising
`mkInteger` in the other builtin Integer rules.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5284#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
