This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [MIPS] Add sbasic supoert ffor MSA (SIMD)


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?

Regards,
Matthew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]