I am testing a very simple patch for Windows and I am looking into other platforms. It looks like GCC might be more tricky: https://bugzilla.mozilla.org/show_bug.cgi?id=521435 https://bugzilla.mozilla.org/show_bug.cgi?id=521435 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 "Optimizing real world applications with GCC Link Time Optimization": Optimizing real world applications with GCC Link Time Optimization

I have looked into this a little bit and am not seeing the same size wins you were in bug 611781. Enabling /GL for objects and /LTCG for DLL links results in an nss3.dll with a ~100K larger .text section, according to dumpbin. .reloc increases by ~8K as well. (Turning on LTCG might also be unsuitable for the .lib files that NSS ships as well, but first it'd be nice to see some wins from it.) Enabling /Gy and /OPT:REF,NOICF has no noticeable effect either. What compiler flags did you flip? I've been doing my testing on the NSS hg tree, not the NSS embedded in mozilla-central, if that makes a difference.

(In reply to Nathan Froyd (:froydnj) from comment #1) > I have looked into this a little bit and am not seeing the same size wins > you were in bug 611781. Enabling /GL for objects and /LTCG for DLL links > results in an nss3.dll with a ~100K larger .text section, according to > dumpbin. .reloc increases by ~8K as well. (Turning on LTCG might also be > unsuitable for the .lib files that NSS ships as well, but first it'd be nice > to see some wins from it.) > > Enabling /Gy and /OPT:REF,NOICF has no noticeable effect either. > > What compiler flags did you flip? I've been doing my testing on the NSS hg > tree, not the NSS embedded in mozilla-central, if that makes a difference. Are you building with BUILD_OPT=1? Please post your patch.

Here's the patch. Building with |make BUILD_OPT=1 nss_build_all|. Looking through the build logs shows that everything is being built with the correct flags.

Nathan, I can't remember what I did in 2010 when I filed this bug but also I can't think of anything differently I would have done then vs. what you did. I think I might have been using VS2008 back then to match what the buildbots were doing, but I'm not certain on that either. It could be the case that LTO is no longer a size win for standalone NSS. I'd encourage you to try building Gecko's combined nss3.dll with LTCG to see if you get different results there. IIRC, a bigger advantage of LTO came about when I started removing unnecessarily-exported symbols from nss.def, especially when I cut down the dependencies (e.g. when I removed the libpkix dependency). But, again, it was a long time ago.