llvm calling convention matters
Carter Schonwald
carter.schonwald at gmail.com
Thu Sep 19 15:42:11 UTC 2013
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> 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's shuffleVector<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>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>> 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
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130919/1092fe16/attachment.htm>
More information about the ghc-devs
mailing list