Hi, I am jumping in somewhat late, as yesterday I was on meetings without internet access. (and I probably will be offline again tomorrow)
I think that in basic terms we all mostly agree (we want to implement optimization scheme that does not get everything into memory, we want to parallelize the post-IPA copmilation). Linker interface seems very fine too. > > WHOPR simply adds another alternative, if you are willing to only run > summary-based transformations, we can split the analysis and > transformation phases in two such that you can parallelize the work > over a cluster or a large SMP. That's it. Nothing more. I think one problem is that both repackaging and cherry picking as described is very centric about application on inlining. It is probably quite clear now, that the list of optimizations we want to perform on LTO scale is going to grow from basic inlining + aliasing combo quite soon. Especially that datastructure changes are starting to kick in. We also would need to sanely support partial offlining, clonning, etc. This IMO should be somehow considered. It is quite possible to implement all this based on summaries, but we need to think of flexibility of the whole scheme and not overly limit it at least in the current stages of implementation. If, for example, we would end up with difficulties to do struct-reorg style transformation that mvoes fields within structure, we would run into problems very soon. I personally always leaned to kind of repackaging scheme. I've hoped that with sanely designed LTO dumping scheme, this will be relatively straighforward to implement: simply you re-use same serialized functions as they are in the original .o files and replace function summaries by transformation summaries, so we might pretty much re-use same infrastructure. With sane caching mechanizm to keeping unmodified function bodies in memory in cooperation in GGC, the repackaging stage should be possible to implement as simple pass through the callgraph writting the selected functions to the output file. One advantage also is that local but non-trivial changes to program can be done at LTO decision time that would simplify the inter-IPA-pass iteraction that seems the most scary issue here. Honza
