#2325: Compile-time computations
--------------------------------------+-------------------------------------
Reporter: ajd | Owner:
Type: run-time performance bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.2
Severity: normal | Resolution:
Keywords: constant folding | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
--------------------------------------+-------------------------------------
Changes (by simonpj):
* difficulty: => Unknown
Comment:
You have to be a bit careful. It's not always the case that
{{{
S# x + S# y = S# (x+y)
}}}
If the sum is too big the result should be a `J#`.
I can think of two ways to do this.
* Add a `BuiltInRule` for `plusInteger` in `prelude/PrelRules.lhs`. But
that would risk getting out of sync with the implementation in the
`integer` package.
* Add a RULE for `GHC.Integer.plusInteger` of form
{{{
plusInteger (S# x) (S# y) = plusIntegerS x y
}}}
and add code to `GHC.Integer` to implement `plusIntegerS`. Something
like
{{{
plusIntegerS :: Int# -> Int# -> Integer
plusIntegerS i j
= case addIntC# i j of
(# r, c #) -> if c ==# 0#
then S# r
else plusInteger (toBigS i1) (toBigS i2)
}}}
Check that `plusIntegerS` will inline when given literals as arguments.
And add a `BuiltInRule` for the `addIntC#` primop.
The latter approach seems better, since it'll benefit all users of
`addIntC#`, but it has the problem that the host platform and target
platform might not have the same beliefs about word size, so it's not
obvious how to do the Right Thing in the `BuiltInRule` for `addIntC#`.
I'm not sure what a good way to solve that is.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2325#comment:2>
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
