> On Mon, Nov 15, 2010 at 5:39 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > >> > Fortunately linker plugin solves the problem here and this is why I want > >> > to > >> > have it by default. GCC then can do effectively -fwhole-program for > >> > binaries > >> > (since linker knows what will be bound elsewhere) and take advantage of > >> > visibility((hidden)) hints for shared libraries same way. Most of > >> > important > >> > shared libraries gets visibility ((hidden)) right. > >> > > >> > It is sad that LTO w/o linker plugin doesn't give that much benefits. > >> > Ideas are welcome here. > >> > >> Linker feedback will be limited here -- mostly global variable > >> aliasing (as I remember only 2/3 spec programs benefit from it), it > >> helps You don't get whole program points-to, whole program mod-ref > >> (with context sensitivity), whole program structure layout. The latter > >> are the real kickers (in terms of SPEC performance), but promoting LTO > >> with those numbers can be misleading as many programs won't get it. > > > > Well, I am speaking of our linker plugin here. What it does is to pass GCC > > resolution information so it knows what symbols are bound externally. Since > > typically you link LTO alone or with small non-LTO part, most of symbols are > > not bound and thus effecitvely you get -fwhole-program (-fwhole-program just > > declare everything static except for main ()) > > > > We don't really do whole program points-to or structure layout. > > gcc will eventually, right?
Sure hope so ;) We really need to solve scalability with our IPA points-to and make it compatible with WHOPR. > > > Mod-ref is just > > simple ipa-reference code. How you get context sensitivity on mod/ref? > > mod-ref relies on points-to. With context sensitive points-to, you can > also get CS mod-ref -- basically mod-ref info per callsite. Ah sure, I was too focused on our current "mod/ref" :) Honza
