Matthew Fortune <matthew.fort...@imgtec.com> writes: > 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?
Yeah, it definitely sounds good in principle. Richard
