> I am wondering whether there is a particular reason why the
> optimiser doesn't pull the
>
> (1) a = NO_CCS PArray! [wild1 mba#];
>
> and the
>
> (2) case w of wild3 {
> I# e# ->
I checked with the before-ghci-branch compiler, and it pulls out (1) but not
(2). Simon did a fai
I can never resist messages like these, even when I'm meant
to be doing other things. It's very helpful when people offer
fairly precise performance-bug reports. Thanks!
| I am wondering whether there is a particular reason why the
| optimiser doesn't pull the
|
| (1) a = NO_CCS PArray! [wi
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote,
> I can never resist messages like these, even when I'm meant
> to be doing other things.
That's good to know ;-)
> It's very helpful when people offer
> fairly precise performance-bug reports. Thanks!
Thanks for the prompt reply! To SimonM, to
PROTECTED]]
| Sent: 02 November 2000 13:54
| To: Simon Peyton-Jones
| Cc: [EMAIL PROTECTED]
| Subject: RE: Fun with GHC's optimiser
|
|
| Simon Peyton-Jones <[EMAIL PROTECTED]> wrote,
|
| > I can never resist messages like these, even when I'm meant
| > to be doing other th
Thu, 7 Dec 2000 09:17:44 -0800, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:
> Try now. On the HEAD. Which should compile OK now, incidentally.
But does not work...
../../ghc/compiler/ghc-inplace -recomp -cpp -fglasgow-exts -fvia-C -icheck -O
-package lang -package concurrent -package po
PArrays.$w$snewPArray
= \ ww :: PrelGHC.Int# w :: PrelBase.Int ->
case PrelGHC.newIntArray# @ PrelGHC.RealWorld ww PrelGHC.realWorld#
of wild { (# s2#, mba# #) ->
let {
eta :: PrelBase.Int
__A 0 __C
eta
= PrelBase.$wI# ww
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote,
> Meanwhile, in the head, if you specify -O2 you'll get better
> code for some of your loops, namely the ones that repeatedly
> evaluate a free variable every time round the loop. The
> loop is duplicated and everything is nice.
[..]
> You mentioned
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote,
> | However, we came across one problem (read, lack of
> | optimisation on GHC's part), which leads to tedious
> | duplication of a lot of code in our array library.
> | Basically, GHC does not recognise for tail recursive
> | functions when certain a
Manuel
| I have found a way of rephrasing the definition so that it
| is properly optimised by GHC. However, I think, it should
| be possible to do this automatically and it is maybe not
| unlike the optimisation done by simplCore/LiberateCase.
I agree with your example. But I think the way to
Simon,
> But I think the way to handle
> it is this. Suppose we have
>
> f x y = (f ex (C a b))...
>
> where C is a constructor, and where y is scrutinised by a
> case expression somewhere in f's body. Then, in this recursive
> call to f, we know what y will be, and we could save t
10 matches
Mail list logo
