Re: [PATCH] Avoid some unnecessary set_cfun calls

[Martin Jambor <mjambor at suse dot cz>]

On Wed, Nov 13, 2013 at 01:53:00PM +0100, Richard Biener wrote:
> On Wed, 13 Nov 2013, Martin Jambor wrote:
> 
> > Hi,
> > 
> > On Wed, Nov 13, 2013 at 10:49:09AM +0100, Jakub Jelinek wrote:
> > > Hi!
> > > 
> > > void f1 (void) {}
> > > __attribute__((target ("avx"))) void f2 (void) {}
> > > __attribute__((target ("avx2"))) void f3 (void) {}
> > > __attribute__((target ("sse3"))) void f4 (void) {}
> > > __attribute__((target ("ssse3"))) void f5 (void) {}
> > > __attribute__((target ("sse4"))) void f6 (void) {}
> > > takes about 3 seconds to compile at -O2, because set_cfun is terribly
> > > expensive and there are hundreds of such calls.
> > > The following patch is just a quick change to avoid some of them:
> > > execute_function_todo starts with:
> > >   unsigned int flags = (size_t)data;
> > >   flags &= ~cfun->last_verified;
> > >   if (!flags)
> > >     return;
> > > and if flags is initially zero, it does nothing.
> > > Similarly, execute_function_dump has the whole body surrounded by
> > >   if (dump_file && current_function_decl)
> > > and thus if dump_file is NULL, there is nothing to do.
> > > So IMHO in neither case (which happens pretty frequently) we need to
> > > set_cfun to every function during IPA.
> > > 
> > > Also, I wonder if we couldn't defer the expensive ira_init, if the info
> > > computed by it is used only during RTL optimization passes (haven't verified
> > > it yet), then supposedly we could just remember using some target hook
> > > what the last state was when we did ira_init last time, and call ira_init
> > > again at the start of expansion or so if it is different from the
> > > last time.
> > 
> > I was wondering whether the expensive parts of set_cfun could only be
> > run in pass_all_optimizations (and the -Og equivalent) but not when
> > changing functions in early and IPA passes.
> 
> Sounds like a hack ;)

Well, a little bit.

> 
> Better get things working without the cfun/current_function_decl globals.
> Wasn't there someone replacing all implicit uses with explicit ones
> for stuff like n_basic_blocks?

I'm not so sure, I think that having an implicit value for the
function parameter makes sense in all intraprocedural passes.  But it
would be great if it was no more than an implicit parameter.

One item on my TODO list is to try and make the at least the
summary-building stages of IPA passes not depend on cfun.  That should
be easy if they did not modify the function bodies.  But PR 54477
shows that they do and the bug has so far scared me away.

Martin