<div dir="ltr">agreed. and the generic vector size stuff in llvm is both pretty naive, AND not the sane/tractable way to add SIMD support to the NCG, <div><br></div><div>i'm totally ok with my vector sizes that are available depending on the target CPU or whatever. Operating systems have very sane errors for that sort of mishap, </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 15, 2017 at 3:29 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@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 dir="ltr">Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it deliberately crashes out during code generation, no? So this is very deliberately <i>not</i> a problem with the current setup as I understand it. It only becomes one if we reverse the decision and decide to add terribly inefficient shims for this functionality at the primop level rather than have a higher level make the right call to just not use functionality that isn't present on the target platform.<span class="HOEnZb"><font color="#888888"><div><div><div><br></div><div>-Edward</div><div><br></div></div></div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari <span dir="ltr"><<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><span>Siddhanathan Shanmugam <<a href="mailto:siddhanathan%2Beml@gmail.com" target="_blank">siddhanathan+eml@gmail.com</a>> writes:<br>
<br>
>> I would be happy to advise if you would like to pick this up.<br>
><br>
> Thanks Ben!<br>
><br>
>> This would mean that Haskell libraries compiled with different flags<br>
>> would not be ABI compatible.<br>
><br>
> Wait, can we not maintain ABI compatibility if we limit the target<br>
> features using a compiler flag? Sometimes (for performance reasons)<br>
> it's reasonable to request the compiler to only generate SSE<br>
> instructions, even if AVX2 is available on the target. On GCC we can<br>
> use the flag -msse to do just that.<br>
><br>
</span>I think the reasoning here is the following (please excuse the rather<br>
contrived example): Consider a function f with two variants,<br>
<br>
    module AvxImpl where<br>
    {-# OPTIONS_GHC -mavx #-}<br>
    f :: DoubleX4# -> DoubleX4# -> Double<br>
<br>
    module SseImpl where<br>
    {-# OPTIONS_GHC -msse #-}<br>
    f :: DoubleX4# -> DoubleX4# -> Double<br>
<br>
If we allow GHC to pass arguments with SIMD registers we now have a bit<br>
of a conundrum: The calling convention for AvxImpl.f will require that<br>
we pass the two arguments in YMM registers, whereas SseImpl.f will<br>
be via passed some other means (perhaps two pairs of XMM registers).<br>
<br>
In the C world this isn't a problem AFAIK since intrinsic types map<br>
directly to register classes. Consequently, I can look at a C<br>
declaration type,<br>
<br>
    double f(__m256 x, __m256 y);<br>
<br>
and tell you precisely the calling convention that would be used. In<br>
GHC, however, we have an abstract vector model and therefore the calling<br>
convention is determined by which ISA the compiler is targetting.<br>
<br>
I really don't know how to fix this "correctly". Currently we assume<br>
that there is a static mapping between STG registers and machine<br>
registers. Giving this up sounds quite painful.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br></div></div><span class="">______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>