Re: Commentary Cmm page (Observations and Areas for Improvement)

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