2009/3/1 Claus Reinke :
> What is the issue with concatMap?
ConcatMap doesn't usually fuse under stream fusion - see
http://www.cse.unsw.edu.au/~dons/papers/stream-fusion.pdf for the gory
details.
> It sounds like your specialization
> is based on the recursion equivalent to loop peeling (unrolli
Yes - this is why my use of a kind of unrolling fixes concatMap for
streams, because GHC is able to specialise the "unrolled" function
body on a particular lambda abstraction. However, this is really a
somewhat seperate issue than plain unrolling, as we just want to be
able to /specialise/ recursi
2009/3/1 Claus Reinke :
> It might be useful to point out that the interaction goes both ways.
> Not only are fused loops candidates for unrolling, but unrolling
> can also enable fusion, giving one example of why Core-level
> unrolling (in addition to backend-level loop restructuring) would
> be u
So now, since we've gone to such effort to produce a tiny loop like, this,
can't we unroll it just a little?
it is worth unrolling this guy, so we get the win of both aggressive high level
fusion, and aggressive low level loop optimisations?
It might be useful to point out that the interaction
Hi GHCi users,
I would like to be able to redefine the built-in GHCi commands. The idea
is that when searching for a command the user defined commands would be
searched first and only then the built-in commands would be searched. If
user wants to invoke a built-in command regardless of user d
Simon Marlow wrote:
Peter Hercek wrote:
Sure, but the plan to maintain an approximate debugging dynamic stack
depends on one thing:
The number of items (continuations) on the return stack from the
beginning of /case tick of {_->e}/ to the moment when we can check
the count of items in the ret
| | A quick grep shows almost no specialization at all for Word, or for
| | IntXX/WordXX (see below). Still, none of that seems to explain the
| | example repeated at the top of this message.
|
| We'd be delighted to apply suitable library patches.
PS: in the case that no one gets around to creat
Malcolm Wallace wrote:
In a lazy language, the dynamic stack rarely tells you anything of
interest for debugging. For the value at the top of the stack, you get
one of many possible _demand_ chains, rather than the creation chain.
The demanding location is pretty-much guaranteed not to be the si
its loop unroller on this guy haven't succeeded. -funroll-loops and
-funroll-all-loops doesn't touch it,
That's because the C produced by GHC doesn't look like a loop to GCC. This can be fixed but given
that we are moving away from -fvia-C anyway, it probably isn't worth doing.
That was on
