Re: Determining live registers on Cmm procedure entry?

On 10/17/2012 04:28 PM, Simon Marlow wrote:
> 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).

Yes, this almost works. Unfortunately splitAtProcPoints doesn't play
nicely---jumps to split procs don't have proper live register info
attached. Looks like I may be back to doing a dataflow analysis
anyway. I will see you Friday :)

Geoff

>>> 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