This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/5] New Identical Code Folding IPA pass

> 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:
> >
> 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

   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.

> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]