Re: llvm calling convention matters

11 Sep 2013


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