<div dir="ltr">solution: lets call these registers what they are, instead of pretending they're portable. we are not going to find the right abstraction in the first go. lets not do that. first get it working sanely, then figure out proper abstractions</div><div class="gmail_extra"><br><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Siddhanathan Shanmugam <<a href="mailto:siddhanathan%2Beml@gmail.com">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>
</blockquote></div><br></div>