llvm calling convention matters

[Geoffrey Mainland]

We did discuss this, but you may not have been present.

If LLVM-only primops show up in a non-LLVM codegen, a "sorry" error is
reported telling the user that they need to compile with "-fllvm". Yes,
this is not a fantastic solution. Options I see:

1) Live with the error message.
2) Remove all SIMD support until the NCG catches up.
3) Figure out a mechanism that avoids inlining any code containing
LLVM-only primops when we're not using the LLVM back end.

Maybe you can think of another solution?

Geoff

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