<p dir="ltr">@carter you&#39;re completely correct, typed template haskell would be very nice for this. </p>
<p dir="ltr">I think something like asStatic would be fine. It would be slightly annoying to not be able to use numeric literals, but it seems like a good first step at any rate. </p>
<p dir="ltr">It would probably be possible to generate a Static value at runtime via the ghc api. But perhaps not, I haven&#39;t played with the typed template haskell enough to know. </p>
<p dir="ltr">As to constructions like Static (IORef Int), that seems to capture the semantics of a global IORef, maybe it could be useful for that sort of application? </p>
<div class="gmail_quote">On Sep 20, 2013 3:19 PM, &quot;Carter Schonwald&quot; &lt;<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">@John, thats actually close to the sort of near term proposal i&#39;ve been thinking of too!<div><br></div><div>We could probably make it nicer by using the new typed template haskell (which geoff was/is also working on!).  <a href="http://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal" target="_blank">http://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal</a></div>



<div><br></div><div>With typed template haskell, couldn&#39;t we have something like </div><div><br></div><div>asStatic :: alpha -&gt; TExp (Static alpha),</div><div><br></div><div>where asStatic is the only way to introduce terms with a type (Static alpha)? (ie: we could only introduce static values that are closed, at Th time, which would also prevent us from construction a value of type (Static alpha) at runtime?)</div>



<div><br></div><div>I think that would be enough to introduce the right compile time Static Data property. That would also probably capture the right notion of static for a number of other uses cases (I think. Probably would need a type class constraint on alpha, to rule out crazy things like Static (IORef Int) or the like ).  </div>


<div><br></div><div>we&#39;d probably need to also have a fromStatic :: Static a -&gt; a, too.</div><div><br></div><div>But you&#39;re absolutely right, with a teeny bit of work, we could have at least a near term work around like that. Theres probably some subtlties i&#39;m overlooking though</div>


<div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 20, 2013 at 2:09 PM, John Lato <span dir="ltr">&lt;<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@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"><p dir="ltr">I think Geoffrey&#39;s suggestion is workable, but I wouldn&#39;t like it so much.  The difficulty is that if you aren&#39;t aware of it, it&#39;s possible to build up a large system that you discover is unworkable the first time you try to compile it. </p>




<p dir="ltr">In that sense it&#39;s not too different from Template Haskell staging restrictions, which IIRC exist to deal with exactly this problem. </p>
<p dir="ltr">As the necessity of compile-time constants has shown up at least twice, a more principled solution is worth investigating. </p>
<p dir="ltr">In the meantime, a horrible hack would be something like:</p>
<p dir="ltr">    newtype CStatic v = CStatic ExpQ<br>
    instance Num a =&gt; Num ( CStatic a) where<br>
      fromInteger x = [| x |]</p>
<p dir="ltr">and then the value could be spliced at the call site. Staging restrictions would ensure it&#39;s available at compile time. I guess the instance decl needs Lift too. </p>
<p dir="ltr">Downsides are general hideous-ness, misleading error messages, and the necessity for compiling with template haskell. But you&#39;d get an error if s value isn&#39;t a compile-time constant. (Please don&#39;t put this in ghc, but it&#39;s not so bad as a separate lib).</p>




<p dir="ltr">John L.</p>
<div class="gmail_quote"><div><div>On Sep 19, 2013 3:44 PM, &quot;Geoffrey Mainland&quot; &lt;<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>&gt; wrote:<br type="attribution"></div>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
If you pass a constant, unboxed value to a primop, I assume GHC won&#39;t<br>
ever bind the argument to a value. So although we have no way to enforce<br>
&quot;static const argument&quot; in the type system, if this is a valuable (and<br>
experts-only?) operation, I&#39;m not sure it matters that much if the user<br>
gets an error at code-generation time complaining about non-const arguments.<br>
<br>
Another way to look at it: if we wait until someone enhances the type<br>
system to support the notion of static arguments, we will likely never<br>
have a bit shuffle primitive.<br>
<br>
The other option would be to fall back on a different implementation if<br>
we saw a non-constant argument. I think that would actually be worse<br>
than erroring out, but I&#39;m sure others would disagree.<br>
<br>
Geoff<br>
<br>
On 09/19/2013 11:42 AM, Carter Schonwald wrote:<br>
&gt; tldr; we can&#39;t express / expose the LLVM shuffleVector intrinsic in a<br>
&gt; type safe way that will correctly interact with the static argument<br>
&gt; requirement for associated code generation.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Sep 19, 2013 at 12:40 AM, Carter Schonwald<br>
&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;     yup, i hit a gap in what we can currently express in haskell<br>
&gt;     types. We don&#39;t have a way of expressing static data! I actually<br>
&gt;     put ticket on trac noting<br>
&gt;     this. <a href="http://ghc.haskell.org/trac/ghc/ticket/8107" target="_blank">http://ghc.haskell.org/trac/ghc/ticket/8107</a><br>
&gt;     (note that when i was initially writing the ticket, i incorrectly<br>
&gt;     thought the int# arg to ghc&#39;s prefetch was the locality level<br>
&gt;     rather than a byte offset)<br>
&gt;<br>
&gt;     Currently GHC has no way of expressing &quot;this argument needs to be<br>
&gt;     a static compile/codegen time constant&quot; in surface haskell or<br>
&gt;     core! This means we could at best provide a suite of special cased<br>
&gt;     operations. (eg: we could provide the inter-lane shuffle for<br>
&gt;     swapping halves of YMM registers, and the miniature analogue for<br>
&gt;     XMM), but that would really be missing the point: being able to<br>
&gt;     write complex algorithms that can work completely in registers!<br>
&gt;<br>
&gt;     the vast majority of the simd shuffle operations have certain<br>
&gt;     arguments that need to be compile time static values that are used<br>
&gt;     in the actual code generation. The llvm data model doesn&#39;t express<br>
&gt;     this constraint. This invariant failure was also hit internally<br>
&gt;     recently  via a bug in how GHC generated code  for llvm&#39;s<br>
&gt;     memcopy! <a href="http://ghc.haskell.org/trac/ghc/ticket/8131" target="_blank">http://ghc.haskell.org/trac/ghc/ticket/8131</a><br>
&gt;<br>
&gt;     If we could express llvm&#39;sshuffleVector<br>
&gt;     &lt;<a href="http://llvm.org/docs/LangRef.html#shufflevector-instruction" target="_blank">http://llvm.org/docs/LangRef.html#shufflevector-instruction</a>&gt;<br>
&gt;     intrinsic in a type safe way, then we could express any of them. I<br>
&gt;     would be over the moon if we could expose an operation like<br>
&gt;     shuffleVector, but I dont&#39; think GHC currently can express it in a<br>
&gt;     type safe way that won&#39;t make LLVM vomit.<br>
&gt;<br>
&gt;     I want simd shuffle, but i don&#39;t see how to give the fully general<br>
&gt;     shuffle operations in type safe ways with ghc currently. We need<br>
&gt;     to add support for some notion of static data first! If theres a<br>
&gt;     way, i&#39;m all for it, but I don&#39;t see such a way.<br>
&gt;<br>
&gt;     I hope that answers your question. that seems to be a deep enough<br>
&gt;     issue that theres no way to resolve it with simple engineering in<br>
&gt;     the next few weeks.<br>
&gt;<br>
&gt;     -Carter<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     On Wed, Sep 18, 2013 at 9:41 PM, Geoffrey Mainland<br>
&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;         On 09/18/2013 04:49 PM, Carter Schonwald wrote:<br>
&gt;         &gt; I&#39;ve some thoughts on how to have a better solution, but<br>
&gt;         they are<br>
&gt;         &gt; feasible only on a time scale suitable for 7.10, and not for<br>
&gt;         7.8.<br>
&gt;         &gt;<br>
&gt;         &gt; a hacky solution we could do for 7.8 perhaps is have a<br>
&gt;         warning that<br>
&gt;         &gt; works as follows:<br>
&gt;         &gt;<br>
&gt;         &gt; either<br>
&gt;         &gt; a)<br>
&gt;         &gt; throw a warning on functions that use the SIMD primops, if that<br>
&gt;         &gt; function is being exported by a module, and that function<br>
&gt;         isn&#39;t marked<br>
&gt;         &gt; NOINLINE ? Theres probably a few subtleties to it, and this<br>
&gt;         is just a<br>
&gt;         &gt; naive idea<br>
&gt;         That wouldn&#39;t inform the consumers of a module. And for a<br>
&gt;         library like<br>
&gt;         vector, we definitely want to export unfoldings for code that<br>
&gt;         contains<br>
&gt;         SIMD primops. That&#39;s the only way to get good code out of the<br>
&gt;         library!<br>
&gt;         &gt; b) somehow put both the -fllvm and -fasm core for inlineable<br>
&gt;         functions<br>
&gt;         &gt; in the .hi file? (this one prevents the most problems, but<br>
&gt;         is probably<br>
&gt;         &gt; the most complex work around we could do).<br>
&gt;         The problem being that there *is* no -fasm code...because the NCG<br>
&gt;         doesn&#39;t support SIMD operations. Unless we added a mechanism<br>
&gt;         to have two<br>
&gt;         completely different, but simultaneous, definitions for a<br>
&gt;         function, one<br>
&gt;         for -fasm and one for -fllvm. But that would be a lot of work and<br>
&gt;         couldn&#39;t be done for 7.8.<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt; its worth noting that the LLVM simd in 7.8, either way,<br>
&gt;         won&#39;t support<br>
&gt;         &gt; simd shuffles, which will seriously curtail its general utility,<br>
&gt;         &gt; either way.<br>
&gt;<br>
&gt;         You told me you would send me example use cases, type<br>
&gt;         signatures, etc.<br>
&gt;         Did I miss an email? If this is very important to you, was there a<br>
&gt;         particular difficulty you had implementing these primops?<br>
&gt;<br>
&gt;         &gt; On Wed, Sep 18, 2013 at 4:22 PM, Simon Marlow<br>
&gt;         &lt;<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a> &lt;mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>&gt;<br>
&gt;         &gt; &lt;mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a> &lt;mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>&gt;&gt;&gt; wrote:<br>
&gt;         &gt;<br>
&gt;         &gt;     On 18/09/13 20:01, Geoffrey Mainland wrote:<br>
&gt;         &gt;<br>
&gt;         &gt;         We did discuss this, but you may not have been present.<br>
&gt;         &gt;<br>
&gt;         &gt;         If LLVM-only primops show up in a non-LLVM codegen,<br>
&gt;         a &quot;sorry&quot;<br>
&gt;         &gt;         error is<br>
&gt;         &gt;         reported telling the user that they need to compile with<br>
&gt;         &gt;         &quot;-fllvm&quot;. Yes,<br>
&gt;         &gt;         this is not a fantastic solution. Options I see:<br>
&gt;         &gt;<br>
&gt;         &gt;         1) Live with the error message.<br>
&gt;         &gt;         2) Remove all SIMD support until the NCG catches up.<br>
&gt;         &gt;         3) Figure out a mechanism that avoids inlining any<br>
&gt;         code containing<br>
&gt;         &gt;         LLVM-only primops when we&#39;re not using the LLVM back<br>
&gt;         end.<br>
&gt;         &gt;<br>
&gt;         &gt;         Maybe you can think of another solution?<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;     Those are the three unsatisfactory solutions that I know<br>
&gt;         of.  Even<br>
&gt;         &gt;     if we did (3), the user still wants to know when that is<br>
&gt;         happening<br>
&gt;         &gt;     because they&#39;re getting less good code, so you&#39;d want a<br>
&gt;         warning.<br>
&gt;         &gt;<br>
&gt;         &gt;     One thing we might try to do is automatically enable<br>
&gt;         -fllvm when<br>
&gt;         &gt;     the compilation would otherwise fail.  If LLVM isn&#39;t<br>
&gt;         installed and<br>
&gt;         &gt;     the compilation still fails, it&#39;s no worse than failing<br>
&gt;         to compile<br>
&gt;         &gt;     the module with the sorry error.<br>
&gt;         &gt;<br>
&gt;         &gt;     Simon<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;         Geoff<br>
&gt;         &gt;<br>
&gt;         &gt;         On 09/18/2013 02:54 PM, Simon Marlow wrote:<br>
&gt;         &gt;<br>
&gt;         &gt;             This is slightly problematic.  What if we have a<br>
&gt;         wonderful<br>
&gt;         &gt;             SIMD-enabled vector library that we compile with<br>
&gt;         -fllvm,<br>
&gt;         &gt;             and then use<br>
&gt;         &gt;             it in a program that isn&#39;t compiled with -fllvm,<br>
&gt;         and some<br>
&gt;         &gt;             of the<br>
&gt;         &gt;             wonderful SIMD-enabled functions get inlined?<br>
&gt;          Presumably<br>
&gt;         &gt;             we get a<br>
&gt;         &gt;             panic in the NCG.<br>
&gt;         &gt;<br>
&gt;         &gt;             Did we discuss this before? I have vague<br>
&gt;         memories, but<br>
&gt;         &gt;             don&#39;t remember<br>
&gt;         &gt;             what the outcome was.<br>
&gt;         &gt;<br>
&gt;         &gt;             Cheers,<br>
&gt;         &gt;                  Simon<br>
&gt;         &gt;<br>
&gt;         &gt;             On 12/09/13 03:10, Geoffrey Mainland wrote:<br>
&gt;         &gt;<br>
&gt;         &gt;                 We support compiling some code with -fllvm<br>
&gt;         and some<br>
&gt;         &gt;                 not in the same<br>
&gt;         &gt;                 executable. Otherwise how could users of the<br>
&gt;         Haskell<br>
&gt;         &gt;                 Platform link their<br>
&gt;         &gt;                 -fllvm-compiled code with<br>
&gt;         native-codegen-compiled<br>
&gt;         &gt;                 libraries like<br>
&gt;         &gt;                 base, etc.?<br>
&gt;         &gt;<br>
&gt;         &gt;                 In other words, the LLVM and native back<br>
&gt;         ends use the<br>
&gt;         &gt;                 same calling<br>
&gt;         &gt;                 convention. With my SIMD work, they still<br>
&gt;         use the same<br>
&gt;         &gt;                 calling<br>
&gt;         &gt;                 conventions, but the native codegen can<br>
&gt;         never generate<br>
&gt;         &gt;                 code that uses<br>
&gt;         &gt;                 SIMD instructions.<br>
&gt;         &gt;<br>
&gt;         &gt;                 Geoff<br>
&gt;         &gt;<br>
&gt;         &gt;                 On 09/11/2013 10:03 PM, Johan Tibell wrote:<br>
&gt;         &gt;<br>
&gt;         &gt;                     OK. But that doesn&#39;t create a problem<br>
&gt;         for the code<br>
&gt;         &gt;                     we output with the<br>
&gt;         &gt;                     LLVM backend, no? Or do we support<br>
&gt;         compiling some<br>
&gt;         &gt;                     code 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,<br>
&gt;         Geoffrey Mainland<br>
&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;<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;&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;<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;&gt;&gt;&gt; wrote:<br>
&gt;         &gt;<br>
&gt;         &gt;                           We definitely have interop between the<br>
&gt;         &gt;                     native codegen and the LLVM<br>
&gt;         &gt;                           back<br>
&gt;         &gt;                           end now. Otherwise anyone who<br>
&gt;         wanted to use<br>
&gt;         &gt;                     the LLVM back end<br>
&gt;         &gt;                           would have<br>
&gt;         &gt;                           to build GHC themselves. Interop<br>
&gt;         means that<br>
&gt;         &gt;                     users can install the<br>
&gt;         &gt;                           Haskell Platform and still use<br>
&gt;         -fllvm when<br>
&gt;         &gt;                     it makes 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<br>
&gt;         Tibell wrote:<br>
&gt;         &gt;                           &gt; Do nothing different than you&#39;re<br>
&gt;         doing for<br>
&gt;         &gt;                     7.8, we can sort<br>
&gt;         &gt;                     it out<br>
&gt;         &gt;                           &gt; later. Just put a comment on the<br>
&gt;         primops<br>
&gt;         &gt;                     saying 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;         &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<br>
&gt;         to primops.<br>
&gt;         &gt;                           &gt;<br>
&gt;         &gt;                           &gt; I don&#39;t think we need interop<br>
&gt;         between the<br>
&gt;         &gt;                     native and the LLVM<br>
&gt;         &gt;                           &gt; backends. We don&#39;t have that now<br>
&gt;         do we<br>
&gt;         &gt;                     (i.e. they 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,<br>
&gt;         Geoffrey<br>
&gt;         &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;<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;&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;<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;&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;<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;&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;<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;&gt;&gt;&gt;&gt;<br>
&gt;         &gt;                     wrote:<br>
&gt;         &gt;                           &gt;<br>
&gt;         &gt;                           &gt;     On 09/11/2013 07:44 PM,<br>
&gt;         Johan Tibell<br>
&gt;         &gt;                     wrote:<br>
&gt;         &gt;                           &gt;     &gt; On Wed, Sep 11, 2013 at<br>
&gt;         4:40 PM,<br>
&gt;         &gt;                     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;<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;&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;<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;&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;<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;&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;<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;&gt;&gt;&gt;&gt;<br>
&gt;         &gt;                     wrote:<br>
&gt;         &gt;                           &gt;     &gt; &gt; Do you mean we need a<br>
&gt;         reasonable<br>
&gt;         &gt;                     emulation 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<br>
&gt;         sense that it<br>
&gt;         &gt;                     computes the right<br>
&gt;         &gt;                           result.<br>
&gt;         &gt;                           &gt;     I can<br>
&gt;         &gt;                           &gt;     &gt; see that some code might<br>
&gt;         still want<br>
&gt;         &gt;                     to #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<br>
&gt;         requirement:<br>
&gt;         &gt;                           &gt;<br>
&gt;         &gt;                           &gt;     1) There will not be SIMD in<br>
&gt;         7.8. I<br>
&gt;         &gt;                     just don&#39;t have the<br>
&gt;         &gt;                           time. In fact,<br>
&gt;         &gt;                           &gt;     what SIMD support is there<br>
&gt;         already<br>
&gt;         &gt;                     will have to be<br>
&gt;         &gt;                     removed if we<br>
&gt;         &gt;                           &gt;     cannot<br>
&gt;         &gt;                           &gt;     live with LLVM-only SIMD<br>
&gt;         primops.<br>
&gt;         &gt;                           &gt;<br>
&gt;         &gt;                           &gt;     2) If we also require<br>
&gt;         interop between<br>
&gt;         &gt;                     the LLVM back-end and<br>
&gt;         &gt;                           the native<br>
&gt;         &gt;                           &gt;     codegen, then we cannot pass<br>
&gt;         any SIMD<br>
&gt;         &gt;                     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<br>
&gt;         Simon PJ,<br>
&gt;         &gt;                     is to not support SIMD<br>
&gt;         &gt;                           primops at<br>
&gt;         &gt;                           &gt;     all with the native codegen.<br>
&gt;         If there<br>
&gt;         &gt;                     is a strong feeling<br>
&gt;         &gt;                     that<br>
&gt;         &gt;                           &gt;     this *is<br>
&gt;         &gt;                           &gt;     not* the way to go, the I<br>
&gt;         need to know<br>
&gt;         &gt;                     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;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;         &gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br></div></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">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>
</blockquote></div><br></div>
</blockquote></div>