<div dir="ltr">let me know before the weekend starts.... so i can make time to help if need be (unless Austin gives breathing room on merge window for such a thing)</div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Thu, Sep 12, 2013 at 3:03 PM, Carter Schonwald <span dir="ltr">&lt;<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">emphasis on &quot;very very clear warning&quot;</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 12, 2013 at 3:00 PM, Carter Schonwald <span dir="ltr">&lt;<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">after a bit more reflection: as long as we provide a clear warning that 7.8 may at some point no longer work with llvm 3.4, i&#39;m down for the change. We just need to make it very very clear, that it may stop working. (and have AVX support via passing on the stack with &lt;= 3.3)<div>



<br></div><div>before i go and upstream that patch, could we benchmark how multivector perf fairs with  patched llvm? i don&#39;t have the right hardware for doing the benchmarks you did in your paper...</div><div>
<br></div><div>sorry for being a bit over the top yesterday, i&#39;m just juggling a lot right now :) </div><span><font color="#888888"><div><br></div><div>-Carter</div></font></span></div><div>
<div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Sep 12, 2013 at 2:47 PM, Carter Schonwald <span dir="ltr">&lt;<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div dir="ltr">oh, i didn&#39;t realize you had already done the work! (bah, i&#39;m sorry, i feel terrible)<div><br></div><div>I thought i had communicated ~ a month ago that I was worried about release engineering interaction with making it impossible to then make a subsequent changes more thoughtfully because of the LLVM release cycle. This concern of mine balloned a bit after helping triage a huge number of problems people were hitting with the Clang transition on mac thats underway. </div>




<div><br></div><div>Its actually very easy to package up an llvm with that patch, much simpler than &quot;build GHC from source&quot;. In fact, on OS X, the simplest way to install LLVM by default essentially does a build from source. </div>




<div><br></div><div>Geoff, it&#39;d at least be worth running the benchmarks to measure the work! (and as I said, i&#39;m happy to help)</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Thu, Sep 12, 2013 at 2:30 PM, 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">If users have to do a custom llvm build, we might as well ask them to<br>
build ghc from source too.<br>
<br>
Unless I misunderstood ticket #8033, you were originally quite gung-ho<br>
about changing the LLVM calling conventions to support passing SIMD<br>
vectors of all widths in registers on both x86-32 and -64, getting these<br>
patches into LLVM 3.4, and making sure that GHC 7.8 would support all<br>
this. I spent several days making sure this could happen from the GHC<br>
side. Now that the plan has changed, I will back out that work, and 7.8<br>
will only support passing 128-bit SIMD vectors in registers on x86-64.<br>
Other vectors sizes, and all vectors on x86-32, will be passed on the stack.<br>
<br>
Geoff<br>
<div><br>
On 9/12/13 1:32 PM, Carter Schonwald wrote:<br>
&gt; to repeat:<br>
&gt;<br>
&gt;  I think no one would have object to having a clearly marked,<br>
&gt; experimental -fllvmExpermentalAVX flag that requires building LLVM<br>
&gt; with a specified patch, as a way to showcase your multivector work!<br>
&gt;<br>
&gt; that would evade all of my objections (provided avx is still exposed<br>
&gt; with normal -fllvm, but spilled to stack rather than registers), and<br>
&gt; i&#39;d actually argue in favor of such.<br>
&gt;<br>
&gt; Especially since it would not impose any release cycle constraints  on<br>
&gt; a subsequent, systematic exploration for using XMM / YMM / ZMM  in the<br>
&gt; calling convention going forward.<br>
&gt;<br>
&gt; @Geoff, Simons, Johan, and others: does anyone object to that approach?<br>
&gt;<br>
&gt; applying such a calling convention patch to llvm is really quite<br>
&gt; straightforward, and the build process is pretty zippy after that too.<br>
&gt;<br>
&gt; cheers<br>
&gt; -Carter<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Sep 12, 2013 at 2:34 AM, Carter Schonwald<br>
</div><div>&gt; &lt;<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a> &lt;mailto:<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>&gt;&gt; wrote:<br>




&gt;<br>
&gt;     that said it does occur to me that there is an alternative<br>
&gt;     solution that may be acceptable for everyone!<br>
&gt;<br>
&gt;     what about providing a pseudo compatible way called<br>
&gt;     -fllvm-experimentalAVX (or something), and simply require that for<br>
&gt;     it to be used, the user has an llvm Patched with the YMM simd in<br>
&gt;     register fun call support? internally that could just be an llvm<br>
&gt;     way that trips the logic that puts the first few AVX values in<br>
&gt;     those YMM1-6 slots if they are the first args, so only the stack<br>
&gt;     spilling logic needs be changed?<br>
&gt;<br>
&gt;     (ie it wouldn&#39;t be tied to an llvm version, but rather this pseduo<br>
&gt;     way flag)<br>
&gt;<br>
&gt;     does that make sense?<br>
&gt;<br>
&gt;     either way, i&#39;d really like having avx even if its always spilled<br>
&gt;     to stack at funcalls with standard LLVMs!<br>
&gt;<br>
&gt;     cheers<br>
&gt;     -carter<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     On Thu, Sep 12, 2013 at 2:28 AM, Carter Schonwald<br>
</div>&gt;     &lt;<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a> &lt;mailto:<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>&gt;&gt;<br>




<div><div>&gt;     wrote:<br>
&gt;<br>
&gt;         Geoff,<br>
&gt;<br>
&gt;         a prosaic reason why there *might* be a fundamentally breaking<br>
&gt;         change would be the following idea nathan howell suggested to<br>
&gt;         me this afternoon: change the Sp and SPLim register so that<br>
&gt;         the X86/x86_64 target can use the CPU&#39;s Push and (maybe) Pop<br>
&gt;         instructions for the  stack manipulations, rather than MOV and<br>
&gt;         fam.  see <a href="http://ghc.haskell.org/trac/ghc/ticket/8272" target="_blank">http://ghc.haskell.org/trac/ghc/ticket/8272</a> (which<br>
&gt;         is just what i&#39;ve said). Thats one change thats pretty simple<br>
&gt;         but deep, but likely worth exploring.<br>
&gt;<br>
&gt;<br>
&gt;         i&#39;m saying any ABI change for GHC 7.10, would likely entail<br>
&gt;         patching LLVM 3.4, because thats the only LLVM version likely<br>
&gt;         to come out between now and whenever we get 7.10 out (assuming<br>
&gt;         7.10 lands within the next 8-12 months, which is reasonable<br>
&gt;         since we&#39;ve got noticeably more (amazing) people  helping out<br>
&gt;         lately). Thus, any change there entails either asking the llvm<br>
&gt;         folks to support &gt;1 GHC convention per architecture, or<br>
&gt;         replace the current one!  I&#39;d rather do the latter than the<br>
&gt;         former, when it comes to asking other people to maintain it :)<br>
&gt;         (and llvm engineers do in fact help out maintaining that code)<br>
&gt;<br>
&gt;<br>
&gt;         have you run a Nofib, or even benchmarks restricted to your<br>
&gt;         multivector code, for the current calling convention<br>
&gt;         (including the spilling AVX vectors to the stack thats the<br>
&gt;         current plan i gather) VS passing in registers with an LLVM<br>
&gt;         built using the patches i worked out ~ 2 months ago?  it&#39;d be<br>
&gt;         really easy to build that custom llvm, then run the<br>
&gt;         benchmarks! (i&#39;m happy to help, and ultimately, benchmarks<br>
&gt;         will reveal if its worth while or not! And if the main goal is<br>
&gt;         for your talk, its still valid even if its not in the merge<br>
&gt;         window over the next 4 days).<br>
&gt;<br>
&gt;         I really think its not obvious what the &quot;best&quot; abi<br>
&gt;         change would be! It really will require coming up with a list<br>
&gt;         of variants, implementing them, and running nofib with each<br>
&gt;         variant, which i lack the compute/human time resources to do<br>
&gt;         this week. Modern hardware is complex enough that for<br>
&gt;         something like an ABI change, the only healthy attitude can be<br>
&gt;         &quot;lets benchmark it!&quot;.<br>
&gt;<br>
&gt;         i&#39;d really like any change in calling convention to also<br>
&gt;         improve perf on codes that aren&#39;t explicitly simd! (and a<br>
&gt;         conservative simd only change, blocks/conflicts with that<br>
&gt;         augmentation going forward, and not just for the stack pointer<br>
&gt;         example i mention early)<br>
&gt;<br>
&gt;          Not just scalar floats in simd registers , but perhaps also<br>
&gt;         words/ints !<br>
&gt;<br>
&gt;         (though that latter bit  might be pretty ambitious and subtle,<br>
&gt;         i&#39;ll need to investigate that a bit to see how feasible it may<br>
&gt;         be).<br>
&gt;         SIMD has great support for  ints/words, and any partial abi<br>
&gt;         change on the llvm backend now would make it hard to support<br>
&gt;         that later well (or at least, thats what it looks like to me).<br>
&gt;          actually effectively using simd for scalar ints and words<br>
&gt;         should be doable, but might force us to be a bit more<br>
&gt;         thoughtful on how GHC internally distinguishes ints used for<br>
&gt;         address arithmetic, vs ints used as data.  (interestingly, i&#39;m<br>
&gt;         not sure if any current extent x86 calling convention does that!)<br>
&gt;<br>
&gt;<br>
&gt;             That single change would make 7.10 require a completely<br>
&gt;         different llvm and native code gen convention from our current<br>
&gt;         one, plus touch all of the code gen on x86 architectures.<br>
&gt;<br>
&gt;<br>
&gt;         basically: we&#39;re lucky that everyone builds haskell code from<br>
&gt;         source, so ABI compat across GHC versions is a non issue. BUT,<br>
&gt;         any ABI changes should be backed by benchmarks (at least when<br>
&gt;         the change is performance motivated). Likewise, because we use<br>
&gt;         LLVM as an external dep for the -fllvm backend, we really need<br>
&gt;         to keep how their release cycle interacts with our release<br>
&gt;         cycle, because people use haskell and ghc! which as many like<br>
&gt;         to say, is both a boon and a pain ;).<br>
&gt;<br>
&gt;         Having people hit ghc acting broken with an llvm that was<br>
&gt;         &quot;supported before&quot; is  risky support problem to deal with.<br>
&gt;         having an LLVM head variant support a modified ABI, and then<br>
&gt;         later needing to break it for 7.10 (for one of the possible<br>
&gt;         exploratory reasons above) would lead to a support headache I<br>
&gt;         don&#39;t wish on anyone.<br>
&gt;<br>
&gt;         pardon the verbose answer, but thats my offhand take<br>
&gt;<br>
&gt;         cheers<br>
&gt;         -Carter<br>
&gt;<br>
&gt;<br>
&gt;         On Wed, Sep 11, 2013 at 10:10 PM, Geoffrey Mainland<br>
</div></div><div>&gt;         &lt;<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a> &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt;&gt; wrote:<br>




&gt;<br>
&gt;             We support compiling some code with -fllvm and some not in<br>
&gt;             the same<br>
&gt;             executable. Otherwise how could users of the Haskell<br>
&gt;             Platform link their<br>
&gt;             -fllvm-compiled code with native-codegen-compiled<br>
&gt;             libraries like base, etc.?<br>
&gt;<br>
&gt;             In other words, the LLVM and native back ends use the same<br>
&gt;             calling<br>
&gt;             convention. With my SIMD work, they still use the same calling<br>
&gt;             conventions, but the native codegen can never generate<br>
&gt;             code that uses<br>
&gt;             SIMD instructions.<br>
&gt;<br>
&gt;             Geoff<br>
&gt;<br>
&gt;             On 09/11/2013 10:03 PM, Johan Tibell wrote:<br>
&gt;             &gt; OK. But that doesn&#39;t create a problem for the code we<br>
&gt;             output with the<br>
&gt;             &gt; LLVM backend, no? Or do we support compiling some code<br>
&gt;             with -fllvm and<br>
&gt;             &gt; some not in the same executable?<br>
&gt;             &gt;<br>
&gt;             &gt;<br>
&gt;             &gt; On Wed, Sep 11, 2013 at 6:56 PM, Geoffrey Mainland<br>
&gt;             &gt; &lt;<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a> &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt;<br>
</div><div><div>&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a><br>
&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt;&gt;&gt; wrote:<br>
&gt;             &gt;<br>
&gt;             &gt;     We definitely have interop between the native<br>
&gt;             codegen and the LLVM<br>
&gt;             &gt;     back<br>
&gt;             &gt;     end now. Otherwise anyone who wanted to use the LLVM<br>
&gt;             back end<br>
&gt;             &gt;     would have<br>
&gt;             &gt;     to build GHC themselves. Interop means that users<br>
&gt;             can install the<br>
&gt;             &gt;     Haskell Platform and still use -fllvm when it makes<br>
&gt;             a performance<br>
&gt;             &gt;     difference.<br>
&gt;             &gt;<br>
&gt;             &gt;     Geoff<br>
&gt;             &gt;<br>
&gt;             &gt;     On 09/11/2013 07:59 PM, Johan Tibell wrote:<br>
&gt;             &gt;     &gt; Do nothing different than you&#39;re doing for 7.8, we<br>
&gt;             can sort it out<br>
&gt;             &gt;     &gt; later. Just put a comment on the primops saying<br>
&gt;             they&#39;re<br>
&gt;             &gt;     LLVM-only. See<br>
&gt;             &gt;     &gt; e.g.<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;<br>
&gt;             <a href="https://github.com/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L181" target="_blank">https://github.com/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L181</a><br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt; for an example how to add docs to primops.<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt; I don&#39;t think we need interop between the native<br>
&gt;             and the LLVM<br>
&gt;             &gt;     &gt; backends. We don&#39;t have that now do we (i.e. they<br>
&gt;             use different<br>
&gt;             &gt;     &gt; calling conventions).<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt; On Wed, Sep 11, 2013 at 4:51 PM, Geoffrey Mainland<br>
&gt;             &gt;     &gt; &lt;<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a><br>
&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt; &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a><br>
&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt;&gt;<br>
&gt;             &gt;     &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a><br>
&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt; &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a><br>
&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt;&gt;&gt;&gt; wrote:<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;     On 09/11/2013 07:44 PM, Johan Tibell wrote:<br>
&gt;             &gt;     &gt;     &gt; On Wed, Sep 11, 2013 at 4:40 PM, Geoffrey<br>
&gt;             Mainland<br>
&gt;             &gt;     &gt;     &lt;<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a><br>
&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt; &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a><br>
&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt;&gt;<br>
&gt;             &gt;     &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a><br>
&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt; &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a><br>
&gt;             &lt;mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt;&gt;&gt;&gt; wrote:<br>
&gt;             &gt;     &gt;     &gt; &gt; Do you mean we need a reasonable emulation<br>
&gt;             of the SIMD<br>
&gt;             &gt;     primops for<br>
&gt;             &gt;     &gt;     &gt; &gt; the native codegen?<br>
&gt;             &gt;     &gt;     &gt;<br>
&gt;             &gt;     &gt;     &gt; Yes. Reasonable in the sense that it<br>
&gt;             computes the right<br>
&gt;             &gt;     result.<br>
&gt;             &gt;     &gt;     I can<br>
&gt;             &gt;     &gt;     &gt; see that some code might still want to<br>
&gt;             #ifdef (if the<br>
&gt;             &gt;     fallback isn&#39;t<br>
&gt;             &gt;     &gt;     &gt; fast enough).<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;     Two implications of this requirement:<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;     1) There will not be SIMD in 7.8. I just don&#39;t<br>
&gt;             have the<br>
&gt;             &gt;     time. In fact,<br>
&gt;             &gt;     &gt;     what SIMD support is there already will have<br>
&gt;             to be removed if we<br>
&gt;             &gt;     &gt;     cannot<br>
&gt;             &gt;     &gt;     live with LLVM-only SIMD primops.<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;     2) If we also require interop between the LLVM<br>
&gt;             back-end and<br>
&gt;             &gt;     the native<br>
&gt;             &gt;     &gt;     codegen, then we cannot pass any SIMD vectors in<br>
&gt;             &gt;     registers---they all<br>
&gt;             &gt;     &gt;     must be passed on the stack.<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;     My plan, as discussed with Simon PJ, is to not<br>
&gt;             support SIMD<br>
&gt;             &gt;     primops at<br>
&gt;             &gt;     &gt;     all with the native codegen. If there is a<br>
&gt;             strong feeling that<br>
&gt;             &gt;     &gt;     this *is<br>
&gt;             &gt;     &gt;     not* the way to go, the I need to know ASAP.<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;     Geoff<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;     &gt;<br>
&gt;             &gt;<br>
&gt;             &gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>