| >> This is is where the Cmm implementation details come up: would the | >> caller state *always* save (conversely, the %%op would generate a | >> call) when the %%op contains code that might change the control | >> flow? That would depend on how the control flow might change, as | >> suggested in section 4.4 of your "C-- Extension..." paper, | >> "Informing the optimiser." Does this sound correct? | > | > I think I'm misunderstanding your question. Let me try again | | I was trying to determine the grounds for when a side-effecting | primop would be inlined and when it would be coded as a separate | procedure.
That's a matter for the implementation, not the C--, or Cmm, specification. The user should not care. The implementer makes the usual cost/performance/complexity trade-off, and decides. I think there is no more to it than that. If you are asking what GHC's current code-generator's decisions are, concerning this choice, I couldn't tell you without looking at the code! Simon _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
