debugging why we end up calling the wrapper rather than the
simonpj at microsoft.com
Mon Jun 4 07:44:25 EDT 2007
| 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 rather
| 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.
I suggest you say NOINLINE ; that prevents inlining until the final phases of compilation, which is probably what you want. See if that works.
Meanwhile, I should probably do no w/w for NOINLINE things. I'll postpone until this thread settles.
More information about the Glasgow-haskell-users