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
