This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [MIPS] Add sbasic supoert ffor MSA (SIMD)
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Graham Stott <Graham dot Stott at imgtec dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Ilie Garbacea <Ilie dot Garbacea at imgtec dot com>, Rich Fuhler <Rich dot Fuhler at imgtec dot com>, Doug Gilmore <Doug dot Gilmore at imgtec dot com>
- Date: Wed, 28 May 2014 15:27:59 +0100
- Subject: Re: [MIPS] Add sbasic supoert ffor MSA (SIMD)
- Authentication-results: sourceware.org; auth=none
- References: <83760FF4D445E74A822AAB0E7BFE5F754051CCC4 at KLMAIL01 dot kl dot imgtec dot org> <Pine dot LNX dot 4 dot 64 dot 1405211752490 dot 13941 at digraph dot polyomino dot org dot uk> <6D39441BF12EF246A7ABCE6654B02353540655 at LEMAIL01 dot le dot imgtec dot org>
On 28/05/14 09:03, Matthew Fortune wrote:
>> You shouldn't need to declare __builtin_* functions anyway. And if a
>> function can be represented directly with GNU C vector extensions, it's
>> preferred to implement it that way inline in the header rather than having
>> built-in functions duplicating existing GNU C functionality. (Look at
>> what AArch64 arm_neon.h does where possible, and what ARM arm_neon.h has
>> been moved towards lately. I don't now what the msa.h functions do, so I
>> don't know if this actually applies to any of them - but it's something to
>> consider, so that built-in functions are only defined where actually
>> needed.)
>
> In the aarch64 arm_neon.h header there are a decent number of inline asm
> implementations too instead of builtins. It is not immediately obvious to me
> as to what the deciding factor is between adding a builtin and using inline
> asm when vector extensions do not support the operation. Do you happen to
> know why inline asm is used in places?
>
Speed of implementation. We're gradually replacing these with proper
builtins, but that takes a lot more work.
> This looks like a reasonable idea to use GNU extensions where available. The
> down-side to this approach is that it may be necessary to write quite
> dis-similar headers for LLVM vs GCC which I think is part of the reason why
> the header is written as it is. I don't know if that is a good reason to
> require builtins or not though.
>
I regard these headers as part of the compiler. In an ideal world the
contents of arm_neon.h should be replacable with
#pragma GCC neon_intrinsics
which would make parsing pretty much instantaneous.
It's never that simple, though; sadly :-(
R.