Many thanks! This was extremely helpful, and reduced link time for that binary by an hour. :) Chris On Wed, Jun 23, 2021 at 5:05 AM Kewen.Lin <linkw@xxxxxxxxxxxxx> wrote: > Hi, > > on 2021/6/21 下午9:41, Chris S via Gcc-help wrote: > > Are the capabilities and/or limitations of GCC10 LTO documented anywhere? > > I understand it only at a high level but not with details, and am having > > trouble finding any current information that describes it very clearly. > > Some questions came up recently that I'd like to be able to answer, but > it > > boils down to this: > > > > Is it possible to build static libraries that have LTO optimizations > > applied to the object code they contain (that is, all the code in that > > library is optimized together with LTO), but when built together into a > > final binary, no additional LTO is performed? We have several large, > > static libraries that are mostly unrelated, and are looking for ways to > > reduce a massive increase in build times after moving to g++10, where > > almost 80% of the time is spent in LTO. > > If the compiling time is the concern, maybe it's worth to trying with > LTO parallel build, such as -flto=auto or -flto=n. > > > https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options > > BR, > Kewen > > > Having optimized individual > > libraries but not a global optimized binary might be a reasonable > > tradeoff. Is this possible? > > > > I don't have a good mental model of when "extra information" (GIMPLE) is > > merely included in the code for later use, and when that GIMPLE > information > > is actually used to perform LTO optimizations. (My suspicion is that > it's > > only when building the final binary.) However, if we can build static > > libraries that are already optimized within themselves, a hint of what > > command line options to use would also be very appreciated. > > > > Thanks. > > Chris > > > >
