On 10/17/12, David Terei <[email protected]> wrote:
> On 16 October 2012 14:48, Gabor Greif <[email protected]> wrote:
>> David,
>>
>> this reminds me, I have added a feature bugzilla to LLVM:
>>
>> http://llvm.org/bugs/show_bug.cgi?id=14080
>>
>> May be interesting to discuss it here first.
>
> I think opening a ticket with LLVM is probably a bad move sorry. It's
> not our community and so we want to be careful not to harass them so
> we maintain good-will with them (and they've shown they are willing to
As I've been a contributor to LLVM since 2005, I do not think they'll
understand this as harassment :-) Currently I focus on selling Haskell
*as such* at my workplace, hopefully that will be over in December,
and then I can tackle some of my LLVM enhancement PRs (such as
this one). I just wanted to record some thoughts.
> engage with us and help with us but that is a limited use resource,
> hence conserve!).
>
> Discussion is probably best done on the mailing list. But more
> importantly, we should only pull them into a discussion when we have
> someone committed to working on the problem. That isn't me at this
> point, I don't have time.
I assume you mean this Haskell list (cvs.ghc@).
>
> So if you want to discuss TNTC / LLVM solutions, great! But unless you
> are also prepared to drive the discussion and implement proposed
> solutions, lets keep it internal to GHC.
Yeah, I won't implement anything before discussing this with the relevant
persons (in both communities). Sometimes people have very good arguments
why something is not a good idea.
>
> I think there are ideas right now of how to move forward on TNTC, its
> more a matter of implementing one or two of them to experiment and
> demonstrate results.
Okay, as soon as I am ready to kick, I'll rekindle these threads.
Thanks for your honest opinions,
Gabor
>
> Cheers,
> David
>
>
> Sure.
>
>>
>> Cheers,
>>
>> Gabor
>>
>> On 10/16/12, David Terei <[email protected]> wrote:
>>> What is the problem you face? That you want to allow passing a dynamic
>>> number of float or double arguments? I assume you are keeping it fixed
>>> at 6 still but want to allow those 6 to be either 6 floats, 6 doubles
>>> or any other combination. (Long term is anything that can be put in a
>>> xmm* register...)
>>>
>>> Why do you want Cmm liveness on entry? Is it simply to solve the above
>>> so you can generate specialized function types instead of the
>>> universal one the LLVM backend uses?
>>>
>>> If so, have you tried just using the most general universal type?
>>> e.g., how badly is the generated code affected if you have all
>>> arguments be Doubles and then do type casts on jumps and function
>>> entries?
>>>
>>> This is the original commit I wrote for tracking STG reg liveness:
>>> 4384e146640230399b38cd62e8e5df391f72c3a7
>>> This is the one Simon Marlow wrote to do the same but in the new code
>>> gen: c6a61235aa0baf6f9e8a41c5a771ccc7e32c23a5
>>>
>>> I'd suggest you look at these commits and they should show you where
>>> to get the information from. (I can't remember anymore sorry).
>>>
>>> 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
>>>
>
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
