This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix IPA-SRA with same_body aliases (PR tree-optimization/42508)


> 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.

Honza
> 
> That said, if you prefer that, I can cook up a patch.  The
> cgraphunit.c hunk would be still desirable.
> 
> 	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]