<div dir="ltr">I've some thoughts on how to have a better solution, but they are feasible only on a time scale suitable for 7.10, and not for 7.8.<div><br></div><div>a hacky solution we could do for 7.8 perhaps is have a warning that works as follows:</div>
<div><br></div><div style>either </div><div style>a)</div><div style>throw a warning on functions that use the SIMD primops, if that function is being exported by a module, and that function isn't marked NOINLINE ? Theres probably a few subtleties to it, and this is just a naive idea</div>
<div style>b) somehow put both the -fllvm and -fasm core for inlineable functions in the .hi file? (this one prevents the most problems, but is probably the most complex work around we could do).</div><div style><br></div>
<div style><br></div><div style>its worth noting that the LLVM simd in 7.8, either way, won't support simd shuffles, which will seriously curtail its general utility, either way. </div><div style><br></div><div style>
-Carter</div><div style><br></div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 18, 2013 at 4:22 PM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 18/09/13 20:01, Geoffrey Mainland wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We did discuss this, but you may not have been present.<br>
<br>
If LLVM-only primops show up in a non-LLVM codegen, a "sorry" error is<br>
reported telling the user that they need to compile with "-fllvm". Yes,<br>
this is not a fantastic solution. Options I see:<br>
<br>
1) Live with the error message.<br>
2) Remove all SIMD support until the NCG catches up.<br>
3) Figure out a mechanism that avoids inlining any code containing<br>
LLVM-only primops when we're not using the LLVM back end.<br>
<br>
Maybe you can think of another solution?<br>
</blockquote>
<br></div>
Those are the three unsatisfactory solutions that I know of. Even if we did (3), the user still wants to know when that is happening because they're getting less good code, so you'd want a warning.<br>
<br>
One thing we might try to do is automatically enable -fllvm when the compilation would otherwise fail. If LLVM isn't installed and the compilation still fails, it's no worse than failing to compile the module with the sorry error.<span class="HOEnZb"><font color="#888888"><br>
<br>
Simon</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Geoff<br>
<br>
On 09/18/2013 02:54 PM, Simon Marlow wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is slightly problematic. What if we have a wonderful<br>
SIMD-enabled vector library that we compile with -fllvm, and then use<br>
it in a program that isn't compiled with -fllvm, and some of the<br>
wonderful SIMD-enabled functions get inlined? Presumably we get a<br>
panic in the NCG.<br>
<br>
Did we discuss this before? I have vague memories, but don't remember<br>
what the outcome was.<br>
<br>
Cheers,<br>
Simon<br>
<br>
On 12/09/13 03:10, Geoffrey Mainland wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We support compiling some code with -fllvm and some not in the same<br>
executable. Otherwise how could users of the Haskell Platform link their<br>
-fllvm-compiled code with native-codegen-compiled libraries like<br>
base, etc.?<br>
<br>
In other words, the LLVM and native back ends use the same calling<br>
convention. With my SIMD work, they still use the same calling<br>
conventions, but the native codegen can never generate code that uses<br>
SIMD instructions.<br>
<br>
Geoff<br>
<br>
On 09/11/2013 10:03 PM, Johan Tibell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OK. But that doesn't create a problem for the code we output with the<br>
LLVM backend, no? Or do we support compiling some code with -fllvm and<br>
some not in the same executable?<br>
<br>
<br>
On Wed, Sep 11, 2013 at 6:56 PM, Geoffrey Mainland<br>
<<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a> <mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>>> wrote:<br>
<br>
We definitely have interop between the native codegen and the LLVM<br>
back<br>
end now. Otherwise anyone who wanted to use the LLVM back end<br>
would have<br>
to build GHC themselves. Interop means that users can install the<br>
Haskell Platform and still use -fllvm when it makes a performance<br>
difference.<br>
<br>
Geoff<br>
<br>
On 09/11/2013 07:59 PM, Johan Tibell wrote:<br>
> Do nothing different than you're doing for 7.8, we can sort<br>
it out<br>
> later. Just put a comment on the primops saying they're<br>
LLVM-only. See<br>
> e.g.<br>
><br>
><br>
><br>
<br>
<a href="https://github.com/ghc/ghc/blob/master/compiler/prelude/primops.txt.pp#L181" target="_blank">https://github.com/ghc/ghc/<u></u>blob/master/compiler/prelude/<u></u>primops.txt.pp#L181</a><br>
><br>
> for an example how to add docs to primops.<br>
><br>
> I don't think we need interop between the native and the LLVM<br>
> backends. We don't have that now do we (i.e. they use different<br>
> calling conventions).<br>
><br>
><br>
><br>
> On Wed, Sep 11, 2013 at 4:51 PM, Geoffrey Mainland<br>
> <<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a> <mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>><br>
<mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a> <mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>>><u></u>><br>
wrote:<br>
><br>
> On 09/11/2013 07:44 PM, Johan Tibell wrote:<br>
> > On Wed, Sep 11, 2013 at 4:40 PM, Geoffrey Mainland<br>
> <<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a> <mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>><br>
<mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a> <mailto:<a href="mailto:mainland@apeiron.net" target="_blank">mainland@apeiron.net</a>>><u></u>><br>
wrote:<br>
> > > Do you mean we need a reasonable emulation of the SIMD<br>
primops for<br>
> > > the native codegen?<br>
> ><br>
> > Yes. Reasonable in the sense that it computes the right<br>
result.<br>
> I can<br>
> > see that some code might still want to #ifdef (if the<br>
fallback isn't<br>
> > fast enough).<br>
><br>
> Two implications of this requirement:<br>
><br>
> 1) There will not be SIMD in 7.8. I just don't have the<br>
time. In fact,<br>
> what SIMD support is there already will have to be<br>
removed if we<br>
> cannot<br>
> live with LLVM-only SIMD primops.<br>
><br>
> 2) If we also require interop between the LLVM back-end and<br>
the native<br>
> codegen, then we cannot pass any SIMD vectors in<br>
registers---they all<br>
> must be passed on the stack.<br>
><br>
> My plan, as discussed with Simon PJ, is to not support SIMD<br>
primops at<br>
> all with the native codegen. If there is a strong feeling<br>
that<br>
> this *is<br>
> not* the way to go, the I need to know ASAP.<br>
><br>
> Geoff<br>
><br>
><br>
><br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>