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 Sandiford <rdsandiford at googlemail dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: Mike Stump <mikestump at comcast dot net>, "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>, Richard Earnshaw <rearnsha at arm dot com>
- Date: Tue, 03 Jun 2014 19:57:07 +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> <6D39441BF12EF246A7ABCE6654B02353542003 at LEMAIL01 dot le dot imgtec dot org>
Matthew Fortune <Matthew.Fortune@imgtec.com> writes:
> Mike Stump <mikestump@comcast.net> writes:
>> 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.
>
> Myself and others at IMG would be interested in reviewing/evaluating the
> implementation and assuming it looks useful then we would of course help to
> get it in shape for submission.
>
>> 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.
>
> Can you post the implementation as an RFC? I suspect the python aspect
> will cause the most trouble as GCC builds do not currently require python
> I guess that could change depending on the value added. Otherwise it would
> be a rewrite I guess.
>
> Before digging in too deep though it would be useful to know if RichardS
> would be willing to consider this kind of thing for the MIPS port?
Yeah, it definitely sounds good in principle.
Richard