Peter Tanski wrote:
On Nov 24, 2006, at 2:50 AM, Simon Peyton-Jones wrote:
Peter Tanski wrote:
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.
Quite so. The wiki is intended for implementers, in this case those
who would be interested in implementing new Cmm primitive operators.
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!
According to nativeGen/MachCodeGen.hs, out-of-line primitive operators
(usually floating point operations) seem to be foreign calls. I
suppose a possible addition to Cmm, such as primitive operators with
exceptions, might be inlined but I haven't looked carefully at the
trade-offs.
Floating point PrimOps (eg. sinFloat#) are compiled into
CmmForeignCall (CmmPrim MO_F32_Sin) ...
which the NCG can choose to compile to either a foreign call or an inline
instruction sequence. On x86 (using the x87 instruction set) some of these are
compiled into inline instructions; on x86_64 (using SSE2 for floating point)
they all turn into foriegn calls.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
