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 _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
