Re: Determining live registers on Cmm procedure entry?

On 17/10/12 07:48, Geoffrey Mainland wrote:

> Thanks for the pointers. I've already rewritten the register allocator,
> so I know where the information comes from...it just seems to get lost
> when procedures are created. I was hoping there was a function somewhere
> that could take a CmmProc and tell me what registers it expected live on
> entry, but I don't think such a thing exists. My dumb attempt at writing
> such a function is quickly becoming a full abstract interpreter, so I
> think my best bet is to change CmmProc to include live register info. If
> this turns out to be too painful I may go back to the bitcast idea.

It's not hard to attach this info to a CmmProc when we create it, 
because we create the proc at the same time as inserting the copy-in 
code for the calling convention.  Look at 
StgCmmMonad.emitProcWithStackFrame, and you'll need to change 
mkCallEntry to return the set of live GlobalRegs.  If you get stuck grab 
me when I'm back in Cambridge (Friday).

Cheers,
	Simon



>> Cheers,
>> David
>>
>> On 16 October 2012 03:45, Geoffrey Mainland <[email protected]> wrote:
>>> Hi all,
>>>
>>> I'm working on changing GHC's calling convention to support overlapping
>>> register classes. On x86-64 this will mean that a function can
>>> receive up to
>>> six Float/Double arguments (any mixture) in registers. Right now only
>>> two
>>> Double arguments can be passed in registers on x86-64, even if a
>>> function
>>> takes zero Float arguments---the register classes for Floats and Doubles
>>> cannot overlap even though both are passed in xmm* registers.
>>>
>>> This is working fine with the native back-end, but I'm not sure how
>>> to get
>>> it working with the LLVM back-end. Right now LLVM translates a Cmm
>>> procedure
>>> to an LLVM function of a single universal type( that is, all LLVM
>>> functions
>>> that the LLVM back-end produces for Cmm procedures have the same
>>> type) that
>>> takes all STG registers as arguments. A Cmm procedure call passes all
>>> the
>>> STG registers, although the back-end takes advantage of the liveness
>>> information attached to Cmm jumps to pass undefined values for non-live
>>> registers.
>>>
>>> Now that register classes can overlap, I need to change this. Since
>>> jumps
>>> have liveness information attached, I can simply pass the live
>>> registers.
>>> But when translating Cmm procedures, I need to know which registers
>>> are live
>>> on entry to the procedure.
>>>
>>> The slightly longer-term goal is to add support for passing SSE
>>> vectors in
>>> registers. What I'd like to have ideally is the set of live registers
>>> *and
>>> their Cmm types* at each procedure entry and jump. I envision having a
>>> single STG register class, say X16, for all 128-bit-wide SSE
>>> registers, but
>>> I'd like the Cmm type information when generating LLVM type
>>> signatures so I
>>> can generate the appropriate LLVM types---a 128-bit-wide vector of
>>> 32-bit
>>> integers does not have the same type as a 128-bit-wide vector of double
>>> precision floats.
>>>
>>> I might be able to do without the Cmm type information by inserting
>>> appropriate casts in the generated LLVM code, but I really need the
>>> set of
>>> live registers on entry to a Cmm procedure. I don't see how to get this
>>> unfortunately. Any hints?
>>>
>>> Thanks,
>>> Geoff
>>>
>>> _______________________________________________
>>> Cvs-ghc mailing list
>>> [email protected]
>>> http://www.haskell.org/mailman/listinfo/cvs-ghc
>
>
> _______________________________________________
> Cvs-ghc mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/cvs-ghc