llvm calling convention matters
Geoffrey Mainland
mainland at apeiron.net
Thu Sep 19 20:44:23 UTC 2013
If you pass a constant, unboxed value to a primop, I assume GHC won't
ever bind the argument to a value. So although we have no way to enforce
"static const argument" in the type system, if this is a valuable (and
experts-only?) operation, I'm not sure it matters that much if the user
gets an error at code-generation time complaining about non-const arguments.
Another way to look at it: if we wait until someone enhances the type
system to support the notion of static arguments, we will likely never
have a bit shuffle primitive.
The other option would be to fall back on a different implementation if
we saw a non-constant argument. I think that would actually be worse
than erroring out, but I'm sure others would disagree.
Geoff
On 09/19/2013 11:42 AM, Carter Schonwald wrote:
> tldr; we can't express / expose the LLVM shuffleVector intrinsic in a
> type safe way that will correctly interact with the static argument
> requirement for associated code generation.
>
>
>
>
> On Thu, Sep 19, 2013 at 12:40 AM, Carter Schonwald
> <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>
> yup, i hit a gap in what we can currently express in haskell
> types. We don't have a way of expressing static data! I actually
> put ticket on trac noting
> this. http://ghc.haskell.org/trac/ghc/ticket/8107
> (note that when i was initially writing the ticket, i incorrectly
> thought the int# arg to ghc's prefetch was the locality level
> rather than a byte offset)
>
> Currently GHC has no way of expressing "this argument needs to be
> a static compile/codegen time constant" in surface haskell or
> core! This means we could at best provide a suite of special cased
> operations. (eg: we could provide the inter-lane shuffle for
> swapping halves of YMM registers, and the miniature analogue for
> XMM), but that would really be missing the point: being able to
> write complex algorithms that can work completely in registers!
>
> the vast majority of the simd shuffle operations have certain
> arguments that need to be compile time static values that are used
> in the actual code generation. The llvm data model doesn't express
> this constraint. This invariant failure was also hit internally
> recently via a bug in how GHC generated code for llvm's
> memcopy! http://ghc.haskell.org/trac/ghc/ticket/8131
>
> If we could express llvm'sshuffleVector
> <http://llvm.org/docs/LangRef.html#shufflevector-instruction>
> intrinsic in a type safe way, then we could express any of them. I
> would be over the moon if we could expose an operation like
> shuffleVector, but I dont' think GHC currently can express it in a
> type safe way that won't make LLVM vomit.
>
> I want simd shuffle, but i don't see how to give the fully general
> shuffle operations in type safe ways with ghc currently. We need
> to add support for some notion of static data first! If theres a
> way, i'm all for it, but I don't see such a way.
>
> I hope that answers your question. that seems to be a deep enough
> issue that theres no way to resolve it with simple engineering in
> the next few weeks.
>
> -Carter
>
>
>
>
> On Wed, Sep 18, 2013 at 9:41 PM, Geoffrey Mainland
> <mainland at apeiron.net <mailto:mainland at apeiron.net>> wrote:
>
> 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>
> > <mailto: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>>
> > <mailto: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>>>
> > <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
> <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>>>
> > <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
> <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