Mike Stump <mikest...@comcast.net> writes: > 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.
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
