Ok so 1) xmm when not using fancy features
2) lets not have types that vary with the abi then! i genuinely think that this is one of those domains where "no abstraction" is a better starting point than "wrong abstraction" I believe both edward kmett and I genuinely want to be users of simd on ghc, and i think in both our cases, it would be markedly simpler to ground the initial work in the ISA / CPU feature level operations/ register flavors rather than trying to get ghc to do the "right abstraction" when we have no experience even trying to bundle it up as a library. Lets get stuff off the ground that doesn't mis-abstract, before we start hunting for the right higher level tools on top. No matter *how* ghc ultimately bundles simd for high level programming, it *will* have to bottom out into these target specific operations at code gen time, and LLVM is *not* an abstraction for it. On Fri, Mar 10, 2017 at 12:50 AM Siddhanathan Shanmugam < siddhanathan+...@gmail.com> wrote: > > It would be even better if we could *also* teach the native back end about > SSE instructions. Is there anyone who might be willing to work on that? > > Yes. Though, it would be better if someone with more experience than me > decides to pick this up instead. > > On Thu, Mar 9, 2017 at 7:00 PM, Edward Kmett <ekm...@gmail.com> wrote: > > If we only turn on ymm and zmm for passing explicit 256bit and 512bit > vector types then changing the ABI would have basically zero effect on any > code anybody is actually using today. Everything would remain abi > compatible unless it involves the new types that nobody is using. > > This also has the benefit that turning on avx2 or avx512 wouldn't change > the calling convention of any code, making it much safer to link code > compiled with it on with code compiled with it off. That seems like a big > deal. > > Moreover, if we start passing normal floats, etc. through them then our > lack of shuffles and ways to get data in/out of them becomes quite a pain > point. > > As for passing int/word data, passing the vectors of them through the ymm > and zmm registers should be sufficient for the same reasons. > > -Edward > > On Thu, Mar 9, 2017 at 3:55 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > > zooming out: > > what *should* the new ABI be? > > Ed was suggesting we make all 16 xmm/ymm/ lower 16 zmm registers > (depending on how they're being used) caller save, > > (what about all 32 zmm registers? would they be float only, or also for > ints/words? simd has lots of nice int support!) > > a) if this doesn't cause any perf regressions i've no objections > > b) currently we only support passing floats/doubles and simd vectors of , > do we wanna support int/word data there too? (or are the GPR / general > purpose registers enough for those? ) > > c) other stuff i'm probably overlooking > > d) lets do this! > > On Thu, Mar 9, 2017 at 3:31 PM, Carter Schonwald < > carter.schonw...@gmail.com> wrote: > > the patch is still on TRAC, > > https://ghc.haskell.org/trac/ghc/ticket/8033 > > we need to do changes to both the 32bit and 64bit ABIs, and I think thats > where I got stalled from lack of feedback > > that aside: > > heres the original email thread on the llvm commits thread > http://lists.llvm.org/pipermail/llvm-commits/Week- > of-Mon-20130708/180264.html > > and theres links from there to the iterating on the test suite plus the > original patch > > i'm more than happy to take a weekend to do the leg work, it was pretty > fun last time. > > BUT, we need to agree on what ABI to do, and make sure that those ABI > changes dont create a performance regression for some unexpected reason. > > On Thu, Mar 9, 2017 at 3:11 PM, Geoffrey Mainland <mainl...@apeiron.net> > wrote: > > We would need to get a patch to LLVM accepted to change the GHC calling > convention. > > Now that we commit to a particular version of LLVM, this might be less > of an issue than it once was since we wouldn't have to support versions > of LLVM that didn't support the new calling convention. > > So...how do we get a patch into LLVM? I believe I once had such a patch > ready to go...I will dig around for it, but the change is very small and > easily recreated. > > It would be even better if we could *also* teach the native back end > about SSE instructions. Is there anyone who might be willing to work on > that? > > Geoff > > On 3/9/17 2:30 PM, Edward Kmett wrote: > > Back around 2013, Geoff raised a discussion about fixing up the GHC > > ABI so that the LLVM calling convention could pass 256 bit vector > > types in YMM (and, i suppose now 512 bit vector types in ZMM). > > > > As I recall, this was blocked by some short term concerns about which > > LLVM release was imminent or what have you. Four years on, the exact > > same sort of arguments could be dredged up, but yet in the meantime > > nobody is really using those types for anything. > > > > This still creates a pain point around trying to use these wide types > > today. Spilling rather than passing them in registers adds a LOT of > > overhead to any attempt to use them that virtually erases any benefit > > to having them in the first place. > > > > I started experimenting with writing some custom primops directly in > > llvm so I could do meaningful amounts of work with our SIMD vector > > types by just banging out the code that we can't write in haskell > > directly using llvm assembly, and hoping I could trick LLVM to do link > > time optimization to perhaps inline it, but I'm basically dead in the > > water over the overhead of our current calling convention, before I > > even start, it seems, as if we're spilling them there is no way that > > inlining / LTO could hope to figure out what we're doing out as part > > of the spill to erase that call entirely. > > > > It is rather frustrating that I can't even cheat. =/ > > > > What do we need to do to finally fix this? > > > > -Edward > > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
