<div dir="ltr"><br><div style>I mentioned this in another thread, but Xeon Phi chips have 512-bit AVX, and Intel has apparently implemented support in LLVM for the ispc compiler. Also apparently this hasn&#39;t been merged back yet, but I guess it is only a matter of time.</div>

<div style>The Intel MIC architecture isn&#39;t quite x86 though.<br></div><div style><br></div><div style><a href="https://github.com/ispc/ispc/issues/367">https://github.com/ispc/ispc/issues/367</a><br></div><div style>

<a href="http://gpuscience.com/software/ispc-a-spmd-compiler-with-xeon-and-xeon-phi-support/">http://gpuscience.com/software/ispc-a-spmd-compiler-with-xeon-and-xeon-phi-support/</a><br></div><div style><br></div><div style>

Alexander</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 14, 2013 at 12:29 AM, Geoffrey Mainland <span dir="ltr">&lt;<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I haven&#39;t seen Michael&#39;s patches (where are they btw?), but there is<br>
some extra work to be done to ensure that 256-bit values are passed in<br>
registers. Otherwise adding support for wider vector types is fairly<br>
straightforward.<br>
<br>
The current plan is for 256-bit wide vector primops to always be<br>
available. The programmer can test for the __AVX__ CPP symbol, which<br>
indicates that these primops will be compiled to efficient code. I am<br>
not inclined to add wider vector primops, as there is no current<br>
platform where they can be compiled efficiently.<br>
<br>
Most programmers should use the Multi type family instead of working<br>
with primops (or their boxed wrappers) directly. For example, by using<br>
Multi Double instead of DoubleX2, the programmer will get 256-bit wide<br>
vectors on platforms that support AVX, and 128-bit wide vectors<br>
otherwise. See <a href="https://github.com/mainland/primitive" target="_blank">https://github.com/mainland/primitive</a> for details.<br>
<br>
Geoff<br>
<div class="im"><br>
On 02/13/2013 07:44 AM, Simon Peyton-Jones wrote:<br>
&gt; I believe Geoff is working on adding AVX.  I expect he’d be interested<br>
&gt; in your patches.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Simon<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div>&gt; *From:*<a href="mailto:ghc-devs-bounces@haskell.org">ghc-devs-bounces@haskell.org</a><br>
&gt; [mailto:<a href="mailto:ghc-devs-bounces@haskell.org">ghc-devs-bounces@haskell.org</a>] *On Behalf Of *Carter Schonwald<br>
&gt; *Sent:* 13 February 2013 05:59<br>
&gt; *To:* Michael Baikov<br>
&gt; *Cc:* <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt; *Subject:* Re: Vector primops sizes<br>
<div class="im">&gt;<br>
&gt;<br>
&gt;<br>
&gt; Yes please! having these  (for valid target arches/ CPU targets) would<br>
&gt; be really really valuable for me.<br>
&gt;<br>
&gt; On Feb 13, 2013 12:07 AM, &quot;Michael Baikov&quot; &lt;<a href="mailto:manpacket@gmail.com">manpacket@gmail.com</a><br>
</div><div class="im">&gt; &lt;mailto:<a href="mailto:manpacket@gmail.com">manpacket@gmail.com</a>&gt;&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Recently merged vector primops support only 16 bytes operands - Int32<br>
&gt;&gt; x 4, Double x 2 and so on. Current AVX instructions support 256 bit<br>
&gt;&gt; operands and with simple cut&#39;n&#39;paste work it&#39;s possible to support at<br>
&gt;&gt; least Double x 4 operands. I made those changes and GHC generates<br>
&gt;&gt; (using llvm) proper AVX code using ymm registers. Also it might make<br>
&gt;&gt; sense to support primops for vector types larger than any currently<br>
&gt;&gt; supported primitive types - I have those changes in my branch as well<br>
&gt;&gt; and llvm generates pretty good code as well - those changes might be<br>
&gt;&gt; useful to provide access for llvm shufflevector instruction or writing<br>
&gt;&gt; high performance processing of large vectors - with less potential<br>
&gt;&gt; overhead.<br>
&gt;&gt;<br>
&gt;&gt; Do we want to support larger vectors directly or ghc should be made<br>
&gt;&gt; smart enough to fuse operations with vector primops performed in<br>
&gt;&gt; parallel into larger vectors/registers for llvm? Do we want to provide<br>
&gt;&gt; access to llvm shufflevector instruction?<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; ghc-devs mailing list<br>
</div>&gt;&gt; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a> &lt;mailto:<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>&gt;<br>
&gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<div class="HOEnZb"><div class="h5">&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; ghc-devs mailing list<br>
&gt; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
&gt;<br>
<br>
<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>
</div></div></blockquote></div><br></div>