Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
Hi, > Martin, do you plan to have this pushed in for GCC 4.7? well, there were two patches. I have managed to update and push trough one of them in time (http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00086.html) but unfortunately I have not managed to do the same with the second one. It's recent incarnation is here: BTW, it looked like Maxim's patch for devirtualization through pointers was left out of that first patch. Was that intentional? It seemed like it should have been, given the discussion in the thread. http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00095.html I noticed Richard had a dangling question on that thread, in case you missed it. However, since the stage 1 ended and I still wasn't able to demonstrate any real impact anywhere (other than my semi-silly example attached to that patch), I gave up. It is unfortunate but I also had In the local set of patches that made such an impact on the code quality tests for devirtualization (posted here http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02589.html), this remaining patch does make a notable difference when combined with the others. Even if the other patches that synergize with that one can't make it for 4.7, I still think it would be valuable to get incremental feedback and testing on as many aspects as we can for 4.7 so that integration of further efforts in the 4.8 timeframe are better informed by bug reports, etc. other pressing tasks and the patch does not do anything on simple programs and I have not been able to compile Firefox even without LTO with the current trunk to try it on something complex. I know how that is ;) It is frustrating that Firefox, which is what we were asked to benchmark these devirt improvements on, has failed to compile at all since we were asked for said benchmarks. (I had a week set aside to do nothing but testing and benchmarking, but could only test multiple-iterations with C code due to the state of trunk at that time.) The devirt code quality tests are derived from real-world code, and we verified that the real-world code was optimized successfully in-context once the test was passing (using a 4.6-based toolchain with Maxim's patches). As for open source projects to demonstrate on, scummvm is also a good candidate for these due to its use of pure virtual classes and factory patterns, but it hasn't compiled with LTO in a while, either (bugs posted a few weeks ago). I had previously benchmarked libv8, which also makes use of pure virtual base classes, but that didn't compile due to an ICE the last time I tested. If you have suggestions for an open source C++ codebase that will compile with LTO and current trunk, let me know, and I'll test it to try and show differences without this patch. PS: Thanks for all your work on devirtualization -- it made it much easier to get the additional development and testing funded, which has resulted in amazing improvements to code generation in the primary C++ codebase I work on. -- http://themakingofthemakingof.com
Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
Hi,
On Tue, Nov 22, 2011 at 07:45:39PM +1300, Maxim Kuvyrkov wrote:
> On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
>
> > On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
> >
> >> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
> >>
> >>> However, both of these are really 4.8 material and since the patches
> >>> probably need only minor updates, it might be worthwhile to do that so
> >>> that gcc can handle the "embarrassing" simple cases. So I will do
> >>> that (though it might need to wait for about a week), re-try them on
> >>> Firefox and probably propose them for submission.
> >>
> >> Great! Thank you.
> >
> > Here is one of your patches updated to the latest mainline. Just add
> > water^W changelog.
> >
> > It bootstraps, and I'm regtesting it on x86_64-linux-gnu {-m64,-m32} now.
>
> Ping.
>
> Martin, do you plan to have this pushed in for GCC 4.7?
>
well, there were two patches. I have managed to update and push
trough one of them in time
(http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00086.html) but
unfortunately I have not managed to do the same with the second one.
It's recent incarnation is here:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00095.html
However, since the stage 1 ended and I still wasn't able to
demonstrate any real impact anywhere (other than my semi-silly example
attached to that patch), I gave up. It is unfortunate but I also had
other pressing tasks and the patch does not do anything on simple
programs and I have not been able to compile Firefox even without LTO
with the current trunk to try it on something complex.
Therefore at the moment I see no other option but to queue it to stage 1
again.
Thanks,
Martin
Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
> On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
>
>> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
>>
>>> However, both of these are really 4.8 material and since the patches
>>> probably need only minor updates, it might be worthwhile to do that so
>>> that gcc can handle the "embarrassing" simple cases. So I will do
>>> that (though it might need to wait for about a week), re-try them on
>>> Firefox and probably propose them for submission.
>>
>> Great! Thank you.
>
> Here is one of your patches updated to the latest mainline. Just add water^W
> changelog.
>
> It bootstraps, and I'm regtesting it on x86_64-linux-gnu {-m64,-m32} now.
Ping.
Martin, do you plan to have this pushed in for GCC 4.7?
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
> On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
>
>> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
>>
>>> However, both of these are really 4.8 material and since the patches
>>> probably need only minor updates, it might be worthwhile to do that so
>>> that gcc can handle the "embarrassing" simple cases. So I will do
>>> that (though it might need to wait for about a week), re-try them on
>>> Firefox and probably propose them for submission.
>>
>> Great! Thank you.
>
> Here is one of your patches updated to the latest mainline. Just add water^W
> changelog.
>
> It bootstraps, and I'm regtesting it on x86_64-linux-gnu {-m64,-m32} now.
Attached is a follow up patch to your 2 devirtualization patches. Now that
compute_known_type_jump_func may be called with SSA_NAME argument (from
ipa_try_devirtualize_immediately) we need to make it handle SSA_NAMEs.
One way to do so it to defer the job to detect_type_change_ssa, below patch
implements this approach. Note that the patch relies on detect_type_change to
initialize JFUNC, as is done in your patch at
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01033.html. Without that patch we
need to initialize JFUNC inside compute_known_type_jump_func, which may be a
cleaner solution.
I encourage you to include this small fix in the main body of one of your
patches and claim credit for it. You will spare me a test-submission cycle
that way :-).
Thank you,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
fsf-gcc-devirt-pointers.ChangeLog
Description: Binary data
fsf-gcc-devirt-pointers.patch
Description: Binary data
Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
> On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
>
>> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
>>
>>> However, both of these are really 4.8 material and since the patches
>>> probably need only minor updates, it might be worthwhile to do that so
>>> that gcc can handle the "embarrassing" simple cases. So I will do
>>> that (though it might need to wait for about a week), re-try them on
>>> Firefox and probably propose them for submission.
>>
>> Great! Thank you.
>
> Here is one of your patches updated to the latest mainline. Just add water^W
> changelog.
>
> It bootstraps, and I'm regtesting it on x86_64-linux-gnu {-m64,-m32} now.
The regtest passed fine (C and C++ languages only). The only failure is the
testcase for PR43411, which this patch removes from XFAILs. It seems the
testcase requires your other patch to PASS.
HTH,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
>
>> However, both of these are really 4.8 material and since the patches
>> probably need only minor updates, it might be worthwhile to do that so
>> that gcc can handle the "embarrassing" simple cases. So I will do
>> that (though it might need to wait for about a week), re-try them on
>> Firefox and probably propose them for submission.
>
> Great! Thank you.
Here is one of your patches updated to the latest mainline. Just add water^W
changelog.
It bootstraps, and I'm regtesting it on x86_64-linux-gnu {-m64,-m32} now.
Regards,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
fsf-gcc-martin-1.patch
Description: Binary data
Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
On 24/09/2011, at 2:19 AM, Martin Jambor wrote: > However, both of these are really 4.8 material and since the patches > probably need only minor updates, it might be worthwhile to do that so > that gcc can handle the "embarrassing" simple cases. So I will do > that (though it might need to wait for about a week), re-try them on > Firefox and probably propose them for submission. Great! Thank you. > > By the way, do you evaluate (your) devirtualization by compiling any > real software (other than Firefox)? Do the patches make any > difference there? The devirtualization and inlining improvements with your patches in the mix provided very good improvements on certain proprietary source base. Code size shrank by 8-10% and performance improved by 3-10% (depending on hardware). There was some amount of parameter tuning involved, so the improvements with default settings will not be as big, but they still should be noticeable. [The testing was done with a 4.6-based toolchain.] The optimizations that we implemented targeted coding patterns that are distilled in the 9 inline-devirt-*.C testcases that I posted. The actual code base was not micro-optimized, and this makes me confident that the improvements are general enough to be valuable to broad bodies of code. Regards, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
Hi, On Thu, Sep 22, 2011 at 06:36:43PM +1200, Maxim Kuvyrkov wrote: > On 9/02/2011, at 6:53 AM, Martin Jambor wrote: > > > > > This patch basically disables all intraprocedural devirtualization > > simply because that transformation relies on assumptions that no > > longer hold true. That leaves only devirtualization within inlining > > and IPA-CP but those do not work intraprocedurally (i.e. when the > > object is within the same function as the call). And in your > > testcase, early inlining puts all virtual calls to main() where the > > objects are. > > > >> > >> GCC mainline just before your patch was optimizing the following > >> testcase to have no virtual calls. I wonder how this can be fixed > >> non-intrusively to qualify for Stage 4. > > > > I have patches for this and hope I will post them soon (probably only as an > > RFC, however). They in fact are in the gcc-patches archives: > > http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01033.html and > > http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01214.html > > > > Unfortunately, I am afraid we would need to make a _very_ compelling > > case for them to be included at this point. > > Martin, > > Ping. > > I am about to submit improvements to inlining that take devirtualization > opportunities into account and your two above patches help improve > devirtualization quite a bit. Do you plan to commit them some time soon? > > For reference, I'm attaching the patch that adds several new devirtualization > testcases. Not optimizing the very simple inline-devirt-1.C is just > embarrassing. > Well, we have tried the patches when LTO-building Firefox in spring and they did not really bring about much improvement. Therefore we concluded that more is needed - such as try to track malloced objects and do devirtualization on them whenever possible because the automatically allocated objects are not enough. Also, because for other reasons (mainly Fortran array info) I plan to implement jump functions for structure components, I planned to eventually replace the new-dynamic-type-identification patch with a jump function for the actual vptr value. However, both of these are really 4.8 material and since the patches probably need only minor updates, it might be worthwhile to do that so that gcc can handle the "embarrassing" simple cases. So I will do that (though it might need to wait for about a week), re-try them on Firefox and probably propose them for submission. By the way, do you evaluate (your) devirtualization by compiling any real software (other than Firefox)? Do the patches make any difference there? Thanks, Martin
Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6
On 9/02/2011, at 6:53 AM, Martin Jambor wrote: > > This patch basically disables all intraprocedural devirtualization > simply because that transformation relies on assumptions that no > longer hold true. That leaves only devirtualization within inlining > and IPA-CP but those do not work intraprocedurally (i.e. when the > object is within the same function as the call). And in your > testcase, early inlining puts all virtual calls to main() where the > objects are. > >> >> GCC mainline just before your patch was optimizing the following >> testcase to have no virtual calls. I wonder how this can be fixed >> non-intrusively to qualify for Stage 4. > > I have patches for this and hope I will post them soon (probably only as an > RFC, however). They in fact are in the gcc-patches archives: > http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01033.html and > http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01214.html > > Unfortunately, I am afraid we would need to make a _very_ compelling > case for them to be included at this point. Martin, Ping. I am about to submit improvements to inlining that take devirtualization opportunities into account and your two above patches help improve devirtualization quite a bit. Do you plan to commit them some time soon? For reference, I'm attaching the patch that adds several new devirtualization testcases. Not optimizing the very simple inline-devirt-1.C is just embarrassing. Thank you, -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics fsf-gcc-devirt-testcases.patch Description: Binary data
