On Thu, May 20, 2010 at 10:54 PM, Duncan Sands <baldr...@free.fr> wrote: > I noticed while working on the dragonegg plugin that replacing gimple -> RTL > with gimple -> LLVM IR significantly reduced the amount of memory used by > the compiler at -O0. I didn't investigate where the memory was going, but > it seems likely that RTL either contains a whole lot more information than > the LLVM IR, or doesn't represent it in a very memory efficient way.
The latter. LLVM IR contains a bit more information (or at least, contains it in a more natural way) but the problem with RTL is, I 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. 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. Ciao! Steven
