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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users