llvm calling convention matters
Geoffrey Mainland
mainland at apeiron.net
Thu Sep 19 01:41:30 UTC 2013
On 09/18/2013 04:49 PM, Carter Schonwald wrote:
> I've some thoughts on how to have a better solution, but they are
> feasible only on a time scale suitable for 7.10, and not for 7.8.
>
> a hacky solution we could do for 7.8 perhaps is have a warning that
> works as follows:
>
> either
> a)
> throw a warning on functions that use the SIMD primops, if that
> function is being exported by a module, and that function isn't marked
> NOINLINE ? Theres probably a few subtleties to it, and this is just a
> naive idea
That wouldn't inform the consumers of a module. And for a library like
vector, we definitely want to export unfoldings for code that contains
SIMD primops. That's the only way to get good code out of the library!
> b) somehow put both the -fllvm and -fasm core for inlineable functions
> in the .hi file? (this one prevents the most problems, but is probably
> the most complex work around we could do).
The problem being that there *is* no -fasm code...because the NCG
doesn't support SIMD operations. Unless we added a mechanism to have two
completely different, but simultaneous, definitions for a function, one
for -fasm and one for -fllvm. But that would be a lot of work and
couldn't be done for 7.8.
>
>
> its worth noting that the LLVM simd in 7.8, either way, won't support
> simd shuffles, which will seriously curtail its general utility,
> either way.
You told me you would send me example use cases, type signatures, etc.
Did I miss an email? If this is very important to you, was there a
particular difficulty you had implementing these primops?
> On Wed, Sep 18, 2013 at 4:22 PM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
>
> 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>
> <mailto: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>>
> <mailto: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>>
> <mailto: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