On Wed, Oct 18, 2006 at 09:48:31AM +0100, Simon Peyton-Jones wrote:
| I would think the easiest way to go about this would be to extend the
| rules pragma.
|
| {-# RULES shift/const-inline forall x y# . shift x y# = ... #-}
|
| where variables ending in # will only match constants known
On Wed, Oct 18, 2006 at 07:00:18AM -0400, [EMAIL PROTECTED] wrote:
I'm not sure this approach is best. In my case the ... needs to be the
entire body of the shift code. It would be ridiculous to have two copies
of the same code. What would be better is a hint pragma that says,
``inline
06:37
| To: glasgow-haskell-users@haskell.org
| Subject: Re: [Haskell] Expecting more inlining for bit shifting
|
| On Mon, Oct 09, 2006 at 03:54:41PM +0100, Ian Lynagh wrote:
| It might be possible, but it sounds tricky. I guess it would have to go
| something like try inlining this, run
On Tue, 17 Oct 2006, John Meacham wrote:
On Mon, Oct 09, 2006 at 03:54:41PM +0100, Ian Lynagh wrote:
It might be possible, but it sounds tricky. I guess it would have to go
something like try inlining this, run the simplifier, see if it got
small enough, if not back out, which could waste a
On Mon, Oct 09, 2006 at 03:54:41PM +0100, Ian Lynagh wrote:
It might be possible, but it sounds tricky. I guess it would have to go
something like try inlining this, run the simplifier, see if it got
small enough, if not back out, which could waste a lot of work if it
fails in lots of cases.
| I might point out that the current code would throw out those
discounts (the
| nukeSrutDiscounts in that case).
Ah yes. I've forgotten why nukeScrutDiscounts is there. If you have
f x = let y = case x of ...
in ...
then the nukeScrutDiscount will avoid giving a
| So, my hypothesis is that the inliner doesn't recognise that
| ``if (x = 0) then ...'' is effectively a case analysis on x, and thus
the
| argument discount is not fired. So we need to figure out how to
extend
| this criterion for when to apply the argument discount.
Correct. GHC generates
On Wed, 11 Oct 2006, Simon Peyton-Jones wrote:
Correct. GHC generates
case (x# =# 0#) of { True - ...; False - ... }
But the argument discount only applies when we have
case y of { ... }
So you really want a discount for the args of a primop.
Do you think it should be that
| Do you think it should be that general? I was thinking the discount
| should only apply in the situtation where a case expression contains
an
| expression with one free varaible that is a function argument, and all
| operations are primitive.
Well, if you see
x =# 0
then it'd be good
On Wed, 11 Oct 2006, Simon Peyton-Jones wrote:
The constant-folding rules for the primops are all in
prelude/PrelRules.lhs
in function primOpRules. Please add more rules. For example, I see
that
x +# 0 = x
is not in there!
It is in libraries/base/GHC/Base.lhs
x# +# 0#
Hello Simon,
Wednesday, October 11, 2006, 2:23:59 PM, you wrote:
The constant-folding rules for the primops are all in
prelude/PrelRules.lhs
in function primOpRules. Please add more rules. For example, I see
that
x +# 0 = x
is not in there!
but GHC.Base contains
{-#
Simon Peyton-Jones simonpj at microsoft.com writes:
| So, my hypothesis is that the inliner doesn't recognise that
| ``if (x = 0) then ...'' is effectively a case analysis on x, and thus
the
| argument discount is not fired. So we need to figure out how to
extend
| this criterion for
On Wed, 11 Oct 2006, Samuel Bronson wrote:
branch. I've got a patch that seems like it ought to do a bettter job,
but it doesn't seem to give the $wrotate functions any discount (the
$wshift functions having been tagged by the {-# INLINE shift #-} pragmas
I added all over). Unfortunately I
| I would have imagined an optimisation step that only activates when a
| constructor is passed into a function to see if it produces a branch
that
| can be precomputed, and then tries to determine if it is worth making
a
| specialized function with that case eliminated. Or possibly having
each
On Tue, 10 Oct 2006, Simon Peyton-Jones wrote:
That's precisely what GHC does. My explanation before was too brief,
sorry. The algorithm is described in Secrets of the GHC inliner
http://research.microsoft.com/%7Esimonpj/Papers/inlining/index.htm
But it still only makes a specialised copy if
e.g. -funfolding-threshold=12
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of
| [EMAIL PROTECTED]
| Sent: 09 October 2006 00:41
| To: haskell@haskell.org
| Subject: [Haskell] Expecting more inlining for bit shifting
|
| Consider the following
On Mon, 9 Oct 2006, Simon Peyton-Jones wrote:
Turns out that 'shift' is just too big to be inlined. (It's only called
once, but you have exported it too.)
You can see GHC's inlining decisions by saying -ddump-inlinings.
To make GHC keener to inline, use an INLINE pragma, or increase the
On Mon, Oct 09, 2006 at 10:33:47AM -0400, [EMAIL PROTECTED] wrote:
On Mon, 9 Oct 2006, Simon Peyton-Jones wrote:
Turns out that 'shift' is just too big to be inlined. (It's only called
once, but you have exported it too.)
You can see GHC's inlining decisions by saying -ddump-inlinings.
October 2006 15:08
| To: Simon Peyton-Jones
| Cc: GHC users
| Subject: RE: [Haskell] Expecting more inlining for bit shifting
|
| On Mon, 9 Oct 2006, Simon Peyton-Jones wrote:
|
| Turns out that 'shift' is just too big to be inlined. (It's only
called
| once, but you have exported it too
Okay, when I force inlining for shift, (and I even need to do it for
shiftR!) then the code is inlined in C. However this isn't the behaviour I
want. Ideally the inlining should only happen when/because the second
argument of shift is constant and the system knows that it can evaluate the
case
20 matches
Mail list logo
