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
