llvm calling convention matters

Simon Marlow marlowsd at gmail.com
Wed Sep 18 18:54:15 UTC 2013


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




More information about the ghc-devs mailing list