possible solution! Re: llvm calling convention matters

12 Sep 2013

      to repeat:

 I think no one would have object to having a clearly marked, experimental
-fllvmExpermentalAVX flag that requires building LLVM with a specified
patch, as a way to showcase your multivector work!

that would evade all of my objections (provided avx is still exposed with
normal -fllvm, but spilled to stack rather than registers), and i'd
actually argue in favor of such.

Especially since it would not impose any release cycle constraints  on a
subsequent, systematic exploration for using XMM / YMM / ZMM  in the
calling convention going forward.

@Geoff, Simons, Johan, and others: does anyone object to that approach?

applying such a calling convention patch to llvm is really quite
straightforward, and the build process is pretty zippy after that too.

cheers
-Carter

On Thu, Sep 12, 2013 at 2:34 AM, Carter Schonwald <
carter.schonwald@gmail.com> wrote:
...
that said it does occur to me that there is an alternative solution that
may be acceptable for everyone!
what about providing a pseudo compatible way called -fllvm-experimentalAVX
(or something), and simply require that for it to be used, the user has an
llvm Patched with the YMM simd in register fun call support? internally
that could just be an llvm way that trips the logic that puts the first few
AVX values in those YMM1-6 slots if they are the first args, so only the
stack spilling logic needs be changed?
(ie it wouldn't be tied to an llvm version, but rather this pseduo way
flag)
does that make sense?
either way, i'd really like having avx even if its always spilled to stack
at funcalls with standard LLVMs!
cheers
-carter
On Thu, Sep 12, 2013 at 2:28 AM, Carter Schonwald <
carter.schonwald@gmail.com> wrote:
...
Geoff,
a prosaic reason why there *might* be a fundamentally breaking change
would be the following idea nathan howell suggested to me this afternoon:
change the Sp and SPLim register so that the X86/x86_64 target can use the
CPU's Push and (maybe) Pop instructions for the  stack manipulations,
rather than MOV and fam.  see http://ghc.haskell.org/trac/ghc/ticket/8272(which is just what i've said). Thats one change thats pretty simple but
deep, but likely worth exploring.
i'm saying any ABI change for GHC 7.10, would likely entail patching LLVM
3.4, because thats the only LLVM version likely to come out between now and
whenever we get 7.10 out (assuming 7.10 lands within the next 8-12 months,
which is reasonable since we've got noticeably more (amazing) people
 helping out lately). Thus, any change there entails either asking the llvm
folks to support >1 GHC convention per architecture, or replace the current
one!  I'd rather do the latter than the former, when it comes to asking
other people to maintain it :)
(and llvm engineers do in fact help out maintaining that code)
have you run a Nofib, or even benchmarks restricted to your multivector
code, for the current calling convention (including the spilling AVX
vectors to the stack thats the current plan i gather) VS passing in
registers with an LLVM built using the patches i worked out ~ 2 months ago?
 it'd be really easy to build that custom llvm, then run the benchmarks!
(i'm happy to help, and ultimately, benchmarks will reveal if its worth
while or not! And if the main goal is for your talk, its still valid even
if its not in the merge window over the next 4 days).
I really think its not obvious what the "best" abi change would be! It
really will require coming up with a list of variants, implementing them,
and running nofib with each variant, which i lack the compute/human time
resources to do this week. Modern hardware is complex enough that for
something like an ABI change, the only healthy attitude can be "lets
benchmark it!".
i'd really like any change in calling convention to also improve perf on
codes that aren't explicitly simd! (and a conservative simd only change,
blocks/conflicts with that augmentation going forward, and not just for the
stack pointer example i mention early)
Not just scalar floats in simd registers , but perhaps also words/ints !
(though that latter bit  might be pretty ambitious and subtle, i'll need
to investigate that a bit to see how feasible it may be).
SIMD has great support for  ints/words, and any partial abi change on the
llvm backend now would make it hard to support that later well (or at
least, thats what it looks like to me).  actually effectively using simd
for scalar ints and words should be doable, but might force us to be a bit
more thoughtful on how GHC internally distinguishes ints used for address
arithmetic, vs ints used as data.  (interestingly, i'm not sure if any
current extent x86 calling convention does that!)
That single change would make 7.10 require a completely different
llvm and native code gen convention from our current one, plus touch all of
the code gen on x86 architectures.
basically: we're lucky that everyone builds haskell code from source, so
ABI compat across GHC versions is a non issue. BUT, any ABI changes should
be backed by benchmarks (at least when the change is performance
motivated). Likewise, because we use LLVM as an external dep for the -fllvm
backend, we really need to keep how their release cycle interacts with our
release cycle, because people use haskell and ghc! which as many like to
say, is both a boon and a pain ;).
Having people hit ghc acting broken with an llvm that was "supported
before" is  risky support problem to deal with. having an LLVM head variant
support a modified ABI, and then later needing to break it for 7.10 (for
one of the possible exploratory reasons above) would lead to a support
headache I don't wish on anyone.
pardon the verbose answer, but thats my offhand take
cheers
-Carter
On Wed, Sep 11, 2013 at 10:10 PM, 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
mailto:mainland@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
    > mailto:mainland@apeiron.net
    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
    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
    >
    >
    >