On Tue, 2007-04-10 at 15:02 -0400, Diego Novillo wrote: > Ian Lance Taylor wrote on 04/10/07 14:13:
> > I would like us to seriously think about this approach. Most of the > > details would be hidden by accessor macros when it comes to actual > > coding. The question is whether we can tolerate some slow down for > > normal processing in return for a benefit to LTO. > > > > If anybody can see how to get the best of both worlds, that would of > > course be even better. > > I've thought about this a little bit and it may not be all that onerous. > So, if you take the components of a tuple: > > next Could be a UID to the next tuple > prev Likewise > bb Use bb->index here > locus Not needed. INSN_LOCATOR. > block Likewise. > > The operands may get tricky, but perhaps not so much. We have > > a- _DECLs. These are easily replaced with their UID and a symbol table. > b- SSA_NAMEs. Just the SSA name version is enough. > c- *_CONST. They're just a bit pattern, no swizzling required. But we > may need to define byte ordering. > c- *_REF. These may be tricky, but we could emit them using a REF table > and just put the index here. > > We then reserve the first few bits to distinguish the class of operand > and the remaining bits as the index into the respective table. I also think this is worth exploring. Probably as a side project once the initial implementation is done. (It would also serve as a proof of interface abstraction :-) And we'd be able to compare what the actual performance hit is and trade it off against the benefits. We'd also be able to "linearize" things when we write it out... ie, flatten out the linked lists of instruction so they are all continguous indexes, tables etc. this would make it compact and when its read in, we might even see some cache friendly accesses for a change. Andrew
