The plan is as I wrote below: 7.8 will only support passing 128-bit SIMD vectors in registers on x86-64. Other vectors sizes, and all vectors on x86-32, will be passed on the stack.
There is not enough time for anything else at his point. Geoff On 09/12/2013 10:40 PM, Carter Schonwald wrote: > let me know before the weekend starts.... so i can make time to help > if need be (unless Austin gives breathing room on merge window for > such a thing) > > > On Thu, Sep 12, 2013 at 3:03 PM, Carter Schonwald > <[email protected] <mailto:[email protected]>> wrote: > > emphasis on "very very clear warning" > > > On Thu, Sep 12, 2013 at 3:00 PM, Carter Schonwald > <[email protected] <mailto:[email protected]>> > wrote: > > after a bit more reflection: as long as we provide a clear > warning that 7.8 may at some point no longer work with llvm > 3.4, i'm down for the change. We just need to make it very > very clear, that it may stop working. (and have AVX support > via passing on the stack with <= 3.3) > > before i go and upstream that patch, could we benchmark how > multivector perf fairs with patched llvm? i don't have the > right hardware for doing the benchmarks you did in your paper... > > sorry for being a bit over the top yesterday, i'm just > juggling a lot right now :) > > -Carter > > > On Thu, Sep 12, 2013 at 2:47 PM, Carter Schonwald > <[email protected] > <mailto:[email protected]>> wrote: > > oh, i didn't realize you had already done the work! (bah, > i'm sorry, i feel terrible) > > I thought i had communicated ~ a month ago that I was > worried about release engineering interaction with making > it impossible to then make a subsequent changes more > thoughtfully because of the LLVM release cycle. This > concern of mine balloned a bit after helping triage a huge > number of problems people were hitting with the Clang > transition on mac thats underway. > > Its actually very easy to package up an llvm with that > patch, much simpler than "build GHC from source". In fact, > on OS X, the simplest way to install LLVM by default > essentially does a build from source. > > Geoff, it'd at least be worth running the benchmarks to > measure the work! (and as I said, i'm happy to help) > > > On Thu, Sep 12, 2013 at 2:30 PM, Geoffrey Mainland > <[email protected] <mailto:[email protected]>> wrote: > > If users have to do a custom llvm build, we might as > well ask them to > build ghc from source too. > > Unless I misunderstood ticket #8033, you were > originally quite gung-ho > about changing the LLVM calling conventions to support > passing SIMD > vectors of all widths in registers on both x86-32 and > -64, getting these > patches into LLVM 3.4, and making sure that GHC 7.8 > would support all > this. I spent several days making sure this could > happen from the GHC > side. Now that the plan has changed, I will back out > that work, and 7.8 > will only support passing 128-bit SIMD vectors in > registers on x86-64. > Other vectors sizes, and all vectors on x86-32, will > be passed on the stack. > > Geoff > > On 9/12/13 1:32 PM, Carter Schonwald wrote: > > to repeat: > > > > I think no one would have object to having a > clearly marked, > > experimental -fllvmExpermentalAVX flag that requires > building LLVM > > with a specified patch, as a way to showcase your > multivector work! > > > > that would evade all of my objections (provided avx > is still exposed > > with normal -fllvm, but spilled to stack rather than > registers), and > > i'd actually argue in favor of such. > > > > Especially since it would not impose any release > cycle constraints on > > a subsequent, systematic exploration for using XMM / > YMM / ZMM in the > > calling convention going forward. > > > > @Geoff, Simons, Johan, and others: does anyone > object to that approach? > > > > applying such a calling convention patch to llvm is > really quite > > straightforward, and the build process is pretty > zippy after that too. > > > > cheers > > -Carter > > > > > > On Thu, Sep 12, 2013 at 2:34 AM, Carter Schonwald > > <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > > that said it does occur to me that there is an > alternative > > solution that may be acceptable for everyone! > > > > what about providing a pseudo compatible way called > > -fllvm-experimentalAVX (or something), and > simply require that for > > it to be used, the user has an llvm Patched with > the YMM simd in > > register fun call support? internally that could > just be an llvm > > way that trips the logic that puts the first few > AVX values in > > those YMM1-6 slots if they are the first args, > so only the stack > > spilling logic needs be changed? > > > > (ie it wouldn't be tied to an llvm version, but > rather this pseduo > > way flag) > > > > does that make sense? > > > > either way, i'd really like having avx even if > its always spilled > > to stack at funcalls with standard LLVMs! > > > > cheers > > -carter > > > > > > > > > > On Thu, Sep 12, 2013 at 2:28 AM, Carter Schonwald > > <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> > > wrote: > > > > Geoff, > > > > a prosaic reason why there *might* be a > fundamentally breaking > > change would be the following idea nathan > howell suggested to > > me this afternoon: change the Sp and SPLim > register so that > > the X86/x86_64 target can use the CPU's Push > and (maybe) Pop > > instructions for the stack manipulations, > rather than MOV and > > fam. see > http://ghc.haskell.org/trac/ghc/ticket/8272 (which > > is just what i've said). Thats one change > thats pretty simple > > but deep, but likely worth exploring. > > > > > > i'm saying any ABI change for GHC 7.10, > would likely entail > > patching LLVM 3.4, because thats the only > LLVM version likely > > to come out between now and whenever we get > 7.10 out (assuming > > 7.10 lands within the next 8-12 months, > which is reasonable > > since we've got noticeably more (amazing) > people helping out > > lately). Thus, any change there entails > either asking the llvm > > folks to support >1 GHC convention per > architecture, or > > replace the current one! I'd rather do the > latter than the > > former, when it comes to asking other people > to maintain it :) > > (and llvm engineers do in fact help out > maintaining that code) > > > > > > have you run a Nofib, or even benchmarks > restricted to your > > multivector code, for the current calling > convention > > (including the spilling AVX vectors to the > stack thats the > > current plan i gather) VS passing in > registers with an LLVM > > built using the patches i worked out ~ 2 > months ago? it'd be > > really easy to build that custom llvm, then > run the > > benchmarks! (i'm happy to help, and > ultimately, benchmarks > > will reveal if its worth while or not! And > if the main goal is > > for your talk, its still valid even if its > not in the merge > > window over the next 4 days). > > > > I really think its not obvious what the > "best" abi > > change would be! It really will require > coming up with a list > > of variants, implementing them, and running > nofib with each > > variant, which i lack the compute/human time > resources to do > > this week. Modern hardware is complex enough > that for > > something like an ABI change, the only > healthy attitude can be > > "lets benchmark it!". > > > > i'd really like any change in calling > convention to also > > improve perf on codes that aren't explicitly > simd! (and a > > conservative simd only change, > blocks/conflicts with that > > augmentation going forward, and not just for > the stack pointer > > example i mention early) > > > > Not just scalar floats in simd registers , > but perhaps also > > words/ints ! > > > > (though that latter bit might be pretty > ambitious and subtle, > > i'll need to investigate that a bit to see > how feasible it may > > be). > > SIMD has great support for ints/words, and > any partial abi > > change on the llvm backend now would make it > hard to support > > that later well (or at least, thats what it > looks like to me). > > actually effectively using simd for scalar > ints and words > > should be doable, but might force us to be a > bit more > > thoughtful on how GHC internally > distinguishes ints used for > > address arithmetic, vs ints used as data. > (interestingly, i'm > > not sure if any current extent x86 calling > convention does that!) > > > > > > That single change would make 7.10 > require a completely > > different llvm and native code gen > convention from our current > > one, plus touch all of the code gen on x86 > architectures. > > > > > > basically: we're lucky that everyone builds > haskell code from > > source, so ABI compat across GHC versions is > a non issue. BUT, > > any ABI changes should be backed by > benchmarks (at least when > > the change is performance motivated). > Likewise, because we use > > LLVM as an external dep for the -fllvm > backend, we really need > > to keep how their release cycle interacts > with our release > > cycle, because people use haskell and ghc! > which as many like > > to say, is both a boon and a pain ;). > > > > Having people hit ghc acting broken with an > llvm that was > > "supported before" is risky support problem > to deal with. > > having an LLVM head variant support a > modified ABI, and then > > later needing to break it for 7.10 (for one > of the possible > > exploratory reasons above) would lead to a > support headache I > > don't wish on anyone. > > > > pardon the verbose answer, but thats my > offhand take > > > > cheers > > -Carter > > > > > > On Wed, Sep 11, 2013 at 10:10 PM, Geoffrey > Mainland > > <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > > We support compiling some code with > -fllvm and some not in > > the same > > executable. Otherwise how could users of > the Haskell > > Platform link their > > -fllvm-compiled code with > native-codegen-compiled > > libraries like base, etc.? > > > > In other words, the LLVM and native back > ends use the same > > calling > > convention. With my SIMD work, they > still use the same calling > > conventions, but the native codegen can > never generate > > code that uses > > SIMD instructions. > > > > Geoff > > > > On 09/11/2013 10:03 PM, Johan Tibell wrote: > > > OK. But that doesn't create a problem > for the code we > > output with the > > > LLVM backend, no? Or do we support > compiling some code > > with -fllvm and > > > some not in the same executable? > > > > > > > > > On Wed, Sep 11, 2013 at 6:56 PM, > Geoffrey Mainland > > > <[email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>> wrote: > > > > > > We definitely have interop between > the native > > codegen and the LLVM > > > back > > > end now. Otherwise anyone who > wanted to use the LLVM > > back end > > > would have > > > to build GHC themselves. Interop > means that users > > can install the > > > Haskell Platform and still use > -fllvm when it makes > > a performance > > > difference. > > > > > > Geoff > > > > > > On 09/11/2013 07:59 PM, Johan > Tibell wrote: > > > > Do nothing different than you're > doing for 7.8, we > > can sort it out > > > > later. Just put a comment on the > primops saying > > they're > > > LLVM-only. See > > > > e.g. > > > > > > > > > > > > > > > > > > > https://github.com/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L181 > > > > > > > > for an example how to add docs > to primops. > > > > > > > > I don't think we need interop > between the native > > and the LLVM > > > > backends. We don't have that now > do we (i.e. they > > use different > > > > calling conventions). > > > > > > > > > > > > > > > > On Wed, Sep 11, 2013 at 4:51 PM, > Geoffrey Mainland > > > > <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>>> wrote: > > > > > > > > On 09/11/2013 07:44 PM, > Johan Tibell wrote: > > > > > On Wed, Sep 11, 2013 at > 4:40 PM, Geoffrey > > Mainland > > > > <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > > <mailto:[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>>> wrote: > > > > > > Do you mean we need a > reasonable emulation > > of the SIMD > > > primops for > > > > > > the native codegen? > > > > > > > > > > Yes. Reasonable in the > sense that it > > computes the right > > > result. > > > > I can > > > > > see that some code might > still want to > > #ifdef (if the > > > fallback isn't > > > > > fast enough). > > > > > > > > Two implications of this > requirement: > > > > > > > > 1) There will not be SIMD in > 7.8. I just don't > > have the > > > time. In fact, > > > > what SIMD support is there > already will have > > to be removed if we > > > > cannot > > > > live with LLVM-only SIMD > primops. > > > > > > > > 2) If we also require > interop between the LLVM > > back-end and > > > the native > > > > codegen, then we cannot pass > any SIMD vectors in > > > registers---they all > > > > must be passed on the stack. > > > > > > > > My plan, as discussed with > Simon PJ, is to not > > support SIMD > > > primops at > > > > all with the native codegen. > If there is a > > strong feeling that > > > > this *is > > > > not* the way to go, the I > need to know ASAP. > > > > > > > > Geoff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
