On Wed, May 28, 2014 at 6:49 PM, Mike Stump <mikest...@comcast.net> wrote:
> On May 28, 2014, at 7:27 AM, Richard Earnshaw <rearn...@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

Reply via email to