llvm calling convention matters

[Simon Marlow]

On 18/09/13 20:01, Geoffrey Mainland wrote:
> 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?

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.

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.

Simon


> 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
>>>>       >
>>>>       >
>>>>       >
>>>>
>>>>
>>>
>>
>