This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 1/5] New Identical Code Folding IPA pass
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Jeff Law <law at redhat dot com>
- Cc: mliska <mliska at suse dot cz>, gcc-patches at gcc dot gnu dot org, hubicka at ucw dot cz
- Date: Wed, 18 Jun 2014 20:59:52 +0200
- Subject: Re: [PATCH 1/5] New Identical Code Folding IPA pass
- Authentication-results: sourceware.org; auth=none
- References: <c5c2463c07186b4ba35b10f3063ecdd8f8d46d63 dot 1402913001 dot git dot mliska at suse dot cz> <53A09BDA dot 5020400 at redhat dot com>
> 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
> 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
> 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
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.