<div dir="ltr">Awesome work Geoff! I look forward to looking at this / playing with it soon!<div><br></div><div>:)</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 3:16 PM, Geoffrey Mainland <span dir="ltr"><<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The SIMD branch, available as wip/simd, is ready for review/merge. It<br>
could use some review---Simon and Simon, I'd be especially grateful if<br>
you both had a quick look. Some major points:<br>
<br>
1) I have added support for AVX 512, although this is necessarily<br>
untested. AVX and AVX2 are also both supported.<br>
<br>
2) After the recent churn regarding patching LLVM's GHC calling<br>
convention, by default only 128-bit wide SIMD vectors are passed in<br>
registers, and then only on X86_64. There is a "hidden" flag,<br>
-fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that<br>
assumes all vectors are passed in registers by LLVM. This can be used<br>
with a suitably patched version of LLVM, and if we get LLVM 3.4 patched,<br>
we can consider turning it on by default for LLVM 3.4+. This would mean<br>
that we couldn't mix LLVM <3.3-compiled object files with LLVM<br>
>3.4-compiled object files, but I don't see that as much of a problem.<br>
<br>
3) utils/genprimcode has been hacked up to allow us to write vector<br>
operations once and have them instantiated at multiple vector types. I'm<br>
not thrilled with this solution, but after discussing with Simon PJ,<br>
what I've implemented seems to be the minimal reasonable solution to the<br>
problem of exploding primop boilerplate. The changes are documented in<br>
compiler/prelude/primops.txt.pp.<br>
<br>
4) Error handling is sub-optimal. My patch checks to make sure that<br>
vector primops can be compiled efficiently based on the current set of<br>
dynamic flags. For example, if -mavx is not specified and the user tries<br>
to use a primop that adds together two 256-bit wide vectors of<br>
double-precision elements, the user will see an error message like:<br>
<br>
ghc-stage2: sorry! (unimplemented feature or known bug)<br>
(GHC version 7.7.20130916 for x86_64-unknown-linux):<br>
256-bit wide floating point SIMD vector instructions require at<br>
least -mavx.<br>
<br>
This is because the only good place to check for this kind of error is<br>
during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we<br>
don't have much of an error handling infrastructure there in contrast to<br>
when we're working in the typechecking/renaming monad. If there is a<br>
better way/place to do this, please let me know.<br>
<br>
Thanks,<br>
Geoff<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div>