Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6

[Matt <matt at use dot net>]

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