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 > <carter.schonw...@gmail.com <mailto:carter.schonw...@gmail.com>> 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 > <carter.schonw...@gmail.com <mailto:carter.schonw...@gmail.com>> > 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 > <mainl...@apeiron.net <mailto:mainl...@apeiron.net>> 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 > > <mainl...@apeiron.net <mailto:mainl...@apeiron.net> > <mailto:mainl...@apeiron.net > <mailto:mainl...@apeiron.net>>> 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 > > > <mainl...@apeiron.net > <mailto:mainl...@apeiron.net> <mailto:mainl...@apeiron.net > <mailto:mainl...@apeiron.net>> > > <mailto:mainl...@apeiron.net > <mailto:mainl...@apeiron.net> <mailto:mainl...@apeiron.net > <mailto:mainl...@apeiron.net>>>> wrote: > > > > > > On 09/11/2013 07:44 PM, Johan Tibell wrote: > > > > On Wed, Sep 11, 2013 at 4:40 PM, Geoffrey > Mainland > > > <mainl...@apeiron.net > <mailto:mainl...@apeiron.net> <mailto:mainl...@apeiron.net > <mailto:mainl...@apeiron.net>> > > <mailto:mainl...@apeiron.net > <mailto:mainl...@apeiron.net> <mailto:mainl...@apeiron.net > <mailto:mainl...@apeiron.net>>>> 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 ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs