This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix IPA-SRA with same_body aliases (PR tree-optimization/42508)
yOn Mon, 4 Jan 2010, Jan Hubicka wrote:
> > On Mon, Jan 04, 2010 at 09:29:42PM +0100, Richard Guenther wrote:
> > > Huh. Are you sure thunks will not get confused with this? After
> > > all the analysis doesn't see what the thunks do and the thunks are
> > > not clones either (and they'll emit a call to the original
> > > function in a way that probably doesn't work anymore).
> >
> > I believe IPA-SRA will refuse to change methods with thunks, because
> > ipa_sra_preliminary_function_checks does:
> > if (DECL_VIRTUAL_P (current_function_decl))
> > {
> > if (dump_file)
> > fprintf (dump_file, "Function is a virtual method.\n");
> > return false;
> > }
>
> This test is IMO wrong and just lead to code quality regressions. I
> remember I was asking for purpose of this one at the time the code went
> in and somehow this was left unresolved. I guess this test is really
> just papering around issues with thunks.
>
> Since methods are most common targets for IPA-SRA, it would be nice to
> see this fixed.
> >
> > > So - why not simply refuse to early-IPA-SRA (that's the only one
> > > that doesnt' work with clones?) functions that have same-body
> > > (or thunk) aliases?
> >
> > Sure, we could give up, but as IMHO thunks aren't considered anyway
> > and dtors can be handled very easily, it would be just a code pessimization.
>
> One option here is to disable that DECL_VIRTUAL_P check and tell IPA-SRA
> to avoid changes on function that do have thunks (but still allow
> aliases).
>
> I think best solution would be to teach statement folding that is
> responsible for turning the indirect calls to virtual method into direct
> call to thunk to simply inline the thunk's code. This way we will get
> all IPA optimizations going smoothly on devirtualized functions with
> thunks.
Sounds something for 4.6 - the existing patch with the (wrong)
check should work ok for now.
Richard.