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]> 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]> 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] >> > 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]>> 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]>>> >>> 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]>>> >>> 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
