Re: Where does the time go?

["Joseph S. Myers" <joseph@codesourcery.com>]

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
joseph@codesourcery.com