possible solution! Re: llvm calling convention matters

Carter Schonwald carter.schonwald at gmail.com
Thu Sep 12 17:32:12 UTC 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 at 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 at 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 <mainland at apeiron.net
>> > 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
>>> >     >
>>> >     >
>>> >     >
>>> >
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130912/7c3d30f6/attachment.htm>


More information about the ghc-devs mailing list