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: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Mike Stump <mikestump at comcast dot net>
- Cc: Richard Earnshaw <rearnsha at arm dot com>, Matthew Fortune <Matthew dot Fortune at imgtec dot com>, "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: Thu, 29 May 2014 10:39:10 +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> <5385F26F dot 2030603 at arm dot com> <48022FA6-3176-4DC0-9E84-2390EF8F2373 at comcast dot net>
- Reply-to: ramrad01 at arm dot com
On Wed, May 28, 2014 at 6:49 PM, Mike Stump <mikestump@comcast.net> wrote:
> On May 28, 2014, at 7:27 AM, Richard Earnshaw <rearnsha@arm.com> wrote:
>>
>> Speed of implementation. We're gradually replacing these with proper
>> builtins, but that takes a lot more work.
>
> As an owner of a port with more builtins that yours, I can offer a technological solution to reduce the cost of builtins to:
>
> (define_builtin âmy_stop"
> [
> (define_outputs [(void_operand 0)])
> (define_rtl_pattern âmy_stop" [])
> ]
> )
>
> (define_insn âmy_stop"
> [(unspec_volatile [(const_int 0)]
> UNSPECV_STOP)]
> ""
> âstopâ)
>
> for example. This creates the builtins, allows overloading, allows input/output parameters, can reorder operands, allows for complex types, allows memory reference parameters, allows pure markings, does vectors, conditional availability, generates documentation, creates test suites and more. If you wire up a speaker it even sings.
>
> Someone would have have to step forward with a need and some time to port their port over to the new scheme and help with the reason for why the technology should go in. It is mostly contained in 5600 lines of self contained python code, and is built to solve the problem generally. It adds about 800 lines to builtins.c. It has a macro system that is more powerful than the macro system .md files use, so one gets to share and collapse builtins rather nicely. It is known to work for C and C++. Other languages may need extending; C for example cost is around 250 lines to support.
>
> One promise, you will never have to create an argument list, or a type, for example here is a two output, type input functional instruction with some doc content:
>
> (define_mode_iterator MYTYPE
> [V8QI V4HI V2SI DI ...])
>
> (define_builtin âmy_fooâ "my_foo2_<type>"
> [
> (define_desc âDoc string for operation")
> (define_outputs [(var_operand:T_MYTYPE 0)
> (var_operand:T_MYTYPE 1)])
> (define_inputs [(var_operand:T_MYTYPE 2)
> (var_operand:T_MYTYPE 3)])
> (define_rtl_pattern âmy_foo2_<mode>" [0 2 1 3])
> (attributes [pure])
> ]
> )
>
> I stripped it so you canât know what the instruction was, but you get a flavor of multiple outputs, doc bits, pure, overloading, arguments and argument rearranging.
>
>
> Let me know if youâre interested.
This sounds interesting - could you post something for an RFC or in a
branch so that one can play with it ?
Ramana