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 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.
Ah, yes of course.
I suggest you say NOINLINE [0]; that prevents inlining until the final phases of compilation, which is probably what you want. See if that works.
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. Duncan