<p dir="ltr">By which I mean having this family of proposed primops. Its not obvious to me at least how GHC could intelligently infer / use these implicitly for the end user / library writer. </p>
<div class="gmail_quote">On Feb 13, 2013 12:07 AM, "Michael Baikov" <<a href="mailto:manpacket@gmail.com">manpacket@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Recently merged vector primops support only 16 bytes operands - Int32<br>
x 4, Double x 2 and so on. Current AVX instructions support 256 bit<br>
operands and with simple cut'n'paste work it's possible to support at<br>
least Double x 4 operands. I made those changes and GHC generates<br>
(using llvm) proper AVX code using ymm registers. Also it might make<br>
sense to support primops for vector types larger than any currently<br>
supported primitive types - I have those changes in my branch as well<br>
and llvm generates pretty good code as well - those changes might be<br>
useful to provide access for llvm shufflevector instruction or writing<br>
high performance processing of large vectors - with less potential<br>
overhead.<br>
<br>
Do we want to support larger vectors directly or ghc should be made<br>
smart enough to fuse operations with vector primops performed in<br>
parallel into larger vectors/registers for llvm? Do we want to provide<br>
access to llvm shufflevector instruction?<br>
<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>