Re: llvm calling convention matters

18 Sep 2013

      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
mailto:mainland@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
      > mailto:mainland@apeiron.net
      mailto:mainland@apeiron.net>>
wrote:
      >
      >     On 09/11/2013 07:44 PM, Johan Tibell wrote:
      >     > On Wed, Sep 11, 2013 at 4:40 PM, Geoffrey Mainland
      >     mailto:mainland@apeiron.net
      mailto:mainland@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
      >
      >
      >