On Mon, May 24, 2010 at 6:20 PM, Mark Mitchell <m...@codesourcery.com> wrote: > Joseph S. Myers wrote: > >>> All in all, perhaps not the most efficient representation for memory >>> foot print, and the pointer chasing probably doesn't help (cache!). >>> But changing it is a lot more difficult than the GIMPLE tuples >>> project. I don't think it can be done. >> >> I don't see any reason technically why it can't be done. There would be >> several large projects, certainly, and nontrivial work in actually >> producing a design for conversion, but there are also clear incremental >> steps, such as static typing of some different kinds of RTL and moving to >> more specific accessors for parts of an RTX in place of generic ones such >> as XEXP used at present. If it can't be done then that would be more for >> economic reasons - no-one benefiting enough from the change, potential >> benefits being gained more cheaply in other ways - than because of >> intrinsic technical obstacles. > > I completely agree. This is a tractable problem, approximately on the > same scale as GIMPLE tuples.
Great you all do semantics :-) So I said "impossible". Perhaps I should have said "of course technically feasible (for the non-faint of heart) but unlikely to happen given the considerable investment required, the technical complexity and risk involved, the unclear and uncertain return-on-investment in both the short and long terms, and perhaps the availability of better options such as the GIMPLE backend (xf. http://gcc.gnu.org/wiki/gimplebackend)". > I would guess approximately a person-year, > perhaps spread out over a longer time. No-one will know for sure, but I think this approximation is a bit too optimistic: * Just in gcc/, all gimple/tree code is less than 200,000 lines of code and all rtl code is >400,000 lines of code. I am not even going to count in config/*. * For RTL if you access XEXP you don't know if you will see an operand or an expression. The GIMPLE tuples project was relatively easy because most GIMPLE passes already access operands through the SSA operands system. * For RTL, expressions can be of arbitrary complexity (machine dependent forms), while for GIMPLE the number of instruction templates is limited. * For RTL, one would have to test many different configurations to avoid breaking things. The code to be modified for GIMPLE tuples was mostly target-independent (compared to all the RTL code in config/*). The GIMPLE tuples work took man-years (note: plural). There was less code to convert and the process of conversion was easier, relatively, than the conversion of RTL would be. So your one person-year seems grossly underestimated. Not that I would discourage anyone from doing the work, but it seems to me that resources would be better spent on something that actually has clear pay-off in the hopefully shorter term (such as http://gcc.gnu.org/wiki/ModularGCC, or indeed http://gcc.gnu.org/wiki/gimplebackend). Ciao! Steven
