debugging why we end up calling the wrapper rather than the
duncan.coutts at worc.ox.ac.uk
Mon Jun 4 08:39:09 EDT 2007
On Mon, 2007-06-04 at 12:44 +0100, Simon Peyton-Jones wrote:
> | So it seems to me that NOINLINE should prevent inlining but not prevent
> | calling the worker rather than the wrapper. I don't fully understand how
> | NOINLINE interacts with the worker/wrapper transform (or I wouldn't have
> | been surprised by this behaviour). I'm guessing that it works by doing
> | the worker/wrapper split and then trying to inline the wrapper into as
> | many call sites as possible. If this is indeed how it works then it'd
> | explain why attaching NOINLINE to the function causes the observed
> | behaviour since looking at the .hi file we see that the NOINLINE is
> | attached to the wrapper function and not the worker.
> Exactly. And indeed, it doesn't really make sense to do a w/w split
> on a NOINLINE thing, if this is what happens.
> | So perhaps the solution is to attach the NOINLINE to the worker
> | than the wrapper when doing the worker/wrapper split. Would that
> work or
> | cause other problems?
> That is easily changed. But consider that you may have put that
> NOININE pragma there to stop the thing inlining so that a RULE would
> fire. We presumably do not want to uncritically make a NOINLINE thing
> into an INLINE thing, just because it's strict; that would nullify the
> carefully set pragmas to make sure the rules worked.
Ah, yes of course.
> I suggest you say NOINLINE ; that prevents inlining until the final
> phases of compilation, which is probably what you want. See if that
But that allows it to be inlined in phase 0, and that's exactly what I
don't want. I really do not want this function inlined, I want it to be
a join point.
So in this example, I'm not trying to do rule matching, I just want to
create a join point.
More information about the Glasgow-haskell-users