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? > 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. Thanks, David > > Honza >> >> David >> >> > >> > Honza >> >> sell lto without -fwhole-program. >> >> >> >> Thanks, >> >> >> >> David >> >> >> >> > Honza >> >> > >> > >
