Haha, cool! I didn't realize you were so involved in the LLVM community, that's great.
I still worry about using up commitment from the LLVM community by involving them in a discussion about TNTC if we don't have the time to truly tackle the challenge right now. That's basically my concern. Given you know the LLVM community better than me it seems, you should decide how best to proceed, i.e., is my opinion correct or not. (either way you should just ignore me :)). Cheers, David On 16 October 2012 16:05, Gabor Greif <[email protected]> wrote: > 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
