> On 06/13/14 04:24, mliska wrote: > > > >You may ask, why the GNU GCC does need such a new optimization. The > >compiler, having simply better knowledge of a compiled source file, > >is capable of reaching better results, especially if Link-Time > >optimization is enabled. Apart from that, GCC implementation adds > >support for read-only variables like construction vtables (mentioned > >in: > >http://hubicka.blogspot.cz/2014/02/devirtualization-in-c-part-3-building.html). > Can you outline at a high level cases where GCC's knowledge allows > it to reach a better result? Is it because you're not requiring bit > for bit identical code, but that the code merely be semantically > equivalent? > > The GCC driven ICF seems to pick up 2X more opportunities than the > gold driven ICF. But if I'm reading everything correctly, that > includes ICF of both functions and variables.
There are important differences between in-GCC ICF and gold's ICF. Basically - GCC ICF runs before most of context sensitive optimizations, so it does see code that is identical to start with, but would become different during optimization. For example if you have function a1...a1000 calling function b1....b1000 where all bX are same, but all aX differs, then before inlining one can easily unify b and let inliner's heuristic decide whether it is good idea to duplicate body of b, while after inlining this is no longer possible. We don't do much in this respect, but we should try to unify accidental code duplication early in early passes to not let duplicates bubble until late optimizations where they may or may not be caught by i.e. tail merging This however also means that at least in current implementation it will result in somewhat more corruption of debug info (by replacing inline functions by different inline function with same body). - GCC ICF (doesn't in the current implementation) can do value numbering matching and match identical semantic with different implementation. It is the plan to get smarter here, I just wanted to have something working first and then play with more advanced tricks. - GCC ICF sees some things as different while they are not in final assembly. Types, alias classes and other details that are important for GCC but lost in codegen. So here gold can do better work. - Theoretically, if tuned well, GCC ICF could improve compilation speed by avoiding need to optimize duplicates. - Gold's ICF depends on functions sections that are not free. - GCC ICF can be smarter about objects with address taken: we need analysis deciding when the address can be compared with a different address. This would be useful on other places, too. Honza > > Do you have any sense of how those improvements break down? ie, is > it mostly more function's you're finding as identical, and if so > what is it about the GCC implementation that allows us to find more > ICF opportunities. If it's mostly variables, that's fine too. I'm > just trying to understand where the improvements are coming from. > > Jeff