On Thu, 20 May 2010, Steven Bosscher wrote: > think, the tree-like representation. If you have an instruction like > (set (a) (b+c)) you could have, at the simples, three integers (insn > uid, basic block, instruction code) and three pointers for operands. > In total, on a 64 bits host: 3*4+3*8 = 36 bytes.
(Plus four bytes padding for alignment.) > An RTL instruction of that form, assuming all operands are registers, > is 6*sizeof(struct rtx_def) = 6*48 = 288 bytes, give or take a few. > Those 6 rtx'en are for: > > 1. insn > 2. set > 3. set_dest operand > 4. set_source: a plus > 5. source operand 1 > 6. source operand 2 > > 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. -- Joseph S. Myers jos...@codesourcery.com
