This is the mail archive of the gcc@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: [tree-ssa] Lazy updating of stmt operands


On Sun, 2003-12-07 at 16:41, Steven Bosscher wrote:
> On Sunday 07 December 2003 18:29, Diego Novillo wrote:
> > > > tree-dfa.c:compute_immediate_uses()
> > >
> > > Which needs to pass through every single statement in the program. Not
> > > really terribly efficient.
> >
> > *shrug*, it's used by SSA-CCP.  Since def-use edges are only needed by
> > some passes, I don't think it would be worth our while trying to
> > maintain them in get_stmt_operands.
> 
> There are going to be more passes that need immediate uses.  Even a simple 
> pass to kill redundant PHIs (say, after unswitching a loop) will have to go 
> over _all_ statements to get the immediate uses of one or two statements.  It 
> would be really nice if there were some way to keep this information 
> up-to-date at all times...

So use get_immidiate_uses() which does what is required on demand, and
if we discover its a serious performance issue down the road, it ought
to be easy enough to change. The interface is abstracted out already.
since operands are cached, a pass through the IL is actually pretty
cheap. Its nothing like the expense of a pass through rtl.

The effort and memory required to keep this information up to date
throughout all compilations would not be insignificant, and until it is
demonstrated that its a win to do so, I wouldn't want to keep it around
all the time.

CCP uses the information, and one of the big compile time and memory
savings on that pass was to optimize the immediate_uses code to only
build it for SSA_NAMEs which we actually cared about. It was a
significant memory hit to build it and have it around for all stmts. 

It would also be possible down the road, if it is an issue, to maintain
the immediate uses information only for as long as it is required. 
Ie, get_stmt_operands could update the immediate_uses info if its
present and we want to keep it up to date. Then if you have a string of
optimizations that want the information, you can keep it up to date
automatically. 

I'd wait until we measure a performance need to do this however. 

Andrew


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