<div dir="ltr"><div>Ok so </div><div><br></div><div>1) xmm when not using fancy features </div><div><br></div><div>2) lets not have types that vary with the abi then!</div><div><br></div><div>i genuinely think that this is one of those domains where "no abstraction" is a better starting point than "wrong abstraction"</div><div><br></div><div>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.</div><div><br></div><div><br><div class="gmail_quote"><div>On Fri, Mar 10, 2017 at 12:50 AM Siddhanathan Shanmugam <<a href="mailto:siddhanathan%2Beml@gmail.com" target="_blank">siddhanathan+eml@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_2732884906588351867gmail_msg">> <span style="font-size:12.8px" class="m_2732884906588351867gmail_msg">It would be even better if we could *also* teach the native back end </span><span style="font-size:12.8px" class="m_2732884906588351867gmail_msg">about SSE instructions. Is there anyone who might be willing to work on </span><span style="font-size:12.8px" class="m_2732884906588351867gmail_msg">that?</span><div class="m_2732884906588351867gmail_msg"><span style="font-size:12.8px" class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></span></div></div><div class="m_2732884906588351867gmail_msg"><div class="m_2732884906588351867gmail_msg"><span style="font-size:12.8px" class="m_2732884906588351867gmail_msg">Yes. Though, it would be better if someone with more experience than me decides to pick this up instead.</span></div></div><div class="gmail_extra m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"><div class="gmail_quote m_2732884906588351867gmail_msg"></div></div><div class="gmail_extra m_2732884906588351867gmail_msg"><div class="gmail_quote m_2732884906588351867gmail_msg">On Thu, Mar 9, 2017 at 7:00 PM, Edward Kmett <span class="m_2732884906588351867gmail_msg"><<a href="mailto:ekmett@gmail.com" class="m_2732884906588351867gmail_msg" target="_blank">ekmett@gmail.com</a>></span> wrote:<br class="m_2732884906588351867gmail_msg"></div></div><div class="gmail_extra m_2732884906588351867gmail_msg"><div class="gmail_quote m_2732884906588351867gmail_msg"><blockquote class="gmail_quote m_2732884906588351867gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_2732884906588351867gmail_msg">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. <div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">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.<div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">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.</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">As for passing int/word data, passing the vectors of them through the ymm and zmm registers should be sufficient for the same reasons.</div><span class="m_2732884906588351867m_208854640124871837HOEnZb m_2732884906588351867gmail_msg"><font color="#888888" class="m_2732884906588351867gmail_msg"><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">-Edward</div></font></span></div></div><div class="m_2732884906588351867m_208854640124871837HOEnZb m_2732884906588351867gmail_msg"><div class="m_2732884906588351867m_208854640124871837h5 m_2732884906588351867gmail_msg"><div class="gmail_extra m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"><div class="gmail_quote m_2732884906588351867gmail_msg">On Thu, Mar 9, 2017 at 3:55 PM, Carter Schonwald <span class="m_2732884906588351867gmail_msg"><<a href="mailto:carter.schonwald@gmail.com" class="m_2732884906588351867gmail_msg" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br class="m_2732884906588351867gmail_msg"><blockquote class="gmail_quote m_2732884906588351867gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_2732884906588351867gmail_msg">zooming out: <div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">what *should* the new ABI be?</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">Ed was suggesting we make all 16 xmm/ymm/ lower 16 zmm registers (depending on how they're being used) caller save, </div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">(what about all 32 zmm registers? would they be float only, or also for ints/words? simd has lots of nice int support!)</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">a) if this doesn't cause any perf regressions i've no objections</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">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? )</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">c) other stuff i'm probably overlooking</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">d) lets do this!</div></div><div class="m_2732884906588351867m_208854640124871837m_-4297016484787374445HOEnZb m_2732884906588351867gmail_msg"><div class="m_2732884906588351867m_208854640124871837m_-4297016484787374445h5 m_2732884906588351867gmail_msg"><div class="gmail_extra m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"><div class="gmail_quote m_2732884906588351867gmail_msg">On Thu, Mar 9, 2017 at 3:31 PM, Carter Schonwald <span class="m_2732884906588351867gmail_msg"><<a href="mailto:carter.schonwald@gmail.com" class="m_2732884906588351867gmail_msg" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br class="m_2732884906588351867gmail_msg"><blockquote class="gmail_quote m_2732884906588351867gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_2732884906588351867gmail_msg">the patch is still on TRAC,<div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg"><a href="https://ghc.haskell.org/trac/ghc/ticket/8033" class="m_2732884906588351867gmail_msg" target="_blank">https://ghc.haskell.org/trac/<wbr>ghc/ticket/8033</a><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">we need to do changes to both the 32bit and 64bit ABIs, and I think thats where I got stalled from lack of feedback</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">that aside:</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">heres the original email thread on the llvm commits thread </div><div class="m_2732884906588351867gmail_msg"><a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130708/180264.html" class="m_2732884906588351867gmail_msg" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-commits/Week-<wbr>of-Mon-20130708/180264.html</a><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">and theres links from there to the iterating on the test suite plus the original patch</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">i'm more than happy to take a weekend to do the leg work, it was pretty fun last time.</div><div class="m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"></div><div class="m_2732884906588351867gmail_msg">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.</div></div><div class="m_2732884906588351867m_208854640124871837m_-4297016484787374445m_-6249088189237429939HOEnZb m_2732884906588351867gmail_msg"><div class="m_2732884906588351867m_208854640124871837m_-4297016484787374445m_-6249088189237429939h5 m_2732884906588351867gmail_msg"><div class="gmail_extra m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg"><div class="gmail_quote m_2732884906588351867gmail_msg">On Thu, Mar 9, 2017 at 3:11 PM, Geoffrey Mainland <span class="m_2732884906588351867gmail_msg"><<a href="mailto:mainland@apeiron.net" class="m_2732884906588351867gmail_msg" target="_blank">mainland@apeiron.net</a>></span> wrote:<br class="m_2732884906588351867gmail_msg"><blockquote class="gmail_quote m_2732884906588351867gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We would need to get a patch to LLVM accepted to change the GHC calling<br class="m_2732884906588351867gmail_msg">
convention.<br class="m_2732884906588351867gmail_msg">
<br class="m_2732884906588351867gmail_msg">
Now that we commit to a particular version of LLVM, this might be less<br class="m_2732884906588351867gmail_msg">
of an issue than it once was since we wouldn't have to support versions<br class="m_2732884906588351867gmail_msg">
of LLVM that didn't support the new calling convention.<br class="m_2732884906588351867gmail_msg">
<br class="m_2732884906588351867gmail_msg">
So...how do we get a patch into LLVM? I believe I once had such a patch<br class="m_2732884906588351867gmail_msg">
ready to go...I will dig around for it, but the change is very small and<br class="m_2732884906588351867gmail_msg">
easily recreated.<br class="m_2732884906588351867gmail_msg">
<br class="m_2732884906588351867gmail_msg">
It would be even better if we could *also* teach the native back end<br class="m_2732884906588351867gmail_msg">
about SSE instructions. Is there anyone who might be willing to work on<br class="m_2732884906588351867gmail_msg">
that?<br class="m_2732884906588351867gmail_msg">
<br class="m_2732884906588351867gmail_msg">
Geoff<br class="m_2732884906588351867gmail_msg">
<div class="m_2732884906588351867m_208854640124871837m_-4297016484787374445m_-6249088189237429939m_6176870787595274040HOEnZb m_2732884906588351867gmail_msg"><div class="m_2732884906588351867m_208854640124871837m_-4297016484787374445m_-6249088189237429939m_6176870787595274040h5 m_2732884906588351867gmail_msg"><br class="m_2732884906588351867gmail_msg">
On 3/9/17 2:30 PM, Edward Kmett wrote:<br class="m_2732884906588351867gmail_msg">
> Back around 2013, Geoff raised a discussion about fixing up the GHC<br class="m_2732884906588351867gmail_msg">
> ABI so that the LLVM calling convention could pass 256 bit vector<br class="m_2732884906588351867gmail_msg">
> types in YMM (and, i suppose now 512 bit vector types in ZMM).<br class="m_2732884906588351867gmail_msg">
><br class="m_2732884906588351867gmail_msg">
> As I recall, this was blocked by some short term concerns about which<br class="m_2732884906588351867gmail_msg">
> LLVM release was imminent or what have you. Four years on, the exact<br class="m_2732884906588351867gmail_msg">
> same sort of arguments could be dredged up, but yet in the meantime<br class="m_2732884906588351867gmail_msg">
> nobody is really using those types for anything.<br class="m_2732884906588351867gmail_msg">
><br class="m_2732884906588351867gmail_msg">
> This still creates a pain point around trying to use these wide types<br class="m_2732884906588351867gmail_msg">
> today. Spilling rather than passing them in registers adds a LOT of<br class="m_2732884906588351867gmail_msg">
> overhead to any attempt to use them that virtually erases any benefit<br class="m_2732884906588351867gmail_msg">
> to having them in the first place.<br class="m_2732884906588351867gmail_msg">
><br class="m_2732884906588351867gmail_msg">
> I started experimenting with writing some custom primops directly in<br class="m_2732884906588351867gmail_msg">
> llvm so I could do meaningful amounts of work with our SIMD vector<br class="m_2732884906588351867gmail_msg">
> types by just banging out the code that we can't write in haskell<br class="m_2732884906588351867gmail_msg">
> directly using llvm assembly, and hoping I could trick LLVM to do link<br class="m_2732884906588351867gmail_msg">
> time optimization to perhaps inline it, but I'm basically dead in the<br class="m_2732884906588351867gmail_msg">
> water over the overhead of our current calling convention, before I<br class="m_2732884906588351867gmail_msg">
> even start, it seems, as if we're spilling them there is no way that<br class="m_2732884906588351867gmail_msg">
> inlining / LTO could hope to figure out what we're doing out as part<br class="m_2732884906588351867gmail_msg">
> of the spill to erase that call entirely.<br class="m_2732884906588351867gmail_msg">
><br class="m_2732884906588351867gmail_msg">
> It is rather frustrating that I can't even cheat. =/<br class="m_2732884906588351867gmail_msg">
><br class="m_2732884906588351867gmail_msg">
> What do we need to do to finally fix this?<br class="m_2732884906588351867gmail_msg">
><br class="m_2732884906588351867gmail_msg">
> -Edward<br class="m_2732884906588351867gmail_msg">
<br class="m_2732884906588351867gmail_msg">
</div></div></blockquote></div><br class="m_2732884906588351867gmail_msg"></div>
</div></div></blockquote></div><br class="m_2732884906588351867gmail_msg"></div>
</div></div></blockquote></div><br class="m_2732884906588351867gmail_msg"></div>
</div></div><br class="m_2732884906588351867gmail_msg"></blockquote></div></div><div class="gmail_extra m_2732884906588351867gmail_msg"><div class="gmail_quote m_2732884906588351867gmail_msg"><blockquote class="gmail_quote m_2732884906588351867gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">______________________________<wbr>_________________<br class="m_2732884906588351867gmail_msg">
ghc-devs mailing list<br class="m_2732884906588351867gmail_msg">
<a href="mailto:ghc-devs@haskell.org" class="m_2732884906588351867gmail_msg" target="_blank">ghc-devs@haskell.org</a><br class="m_2732884906588351867gmail_msg">
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" class="m_2732884906588351867gmail_msg" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br class="m_2732884906588351867gmail_msg">
<br class="m_2732884906588351867gmail_msg"></blockquote></div><br class="m_2732884906588351867gmail_msg"></div>
</blockquote></div></div></div>