This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Lazy updating of stmt operands
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Chris Lattner <sabre at nondot dot org>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, Jeff Law <law at redhat dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: 12 Dec 2003 14:53:54 -0500
- Subject: Re: [tree-ssa] Lazy updating of stmt operands
- References: <Pine.LNX.4.44.0312121345230.16876-100000@nondot.org>
On Fri, 2003-12-12 at 14:46, Chris Lattner wrote:
> > > hardly; you still must scan all statements to find the uses, so I don't
> > > see where you would want to get the extra efficiency.
> > >
> > Scanning stmts is very cheap.
>
> You must not have run across programs that have PHI nodes with thousands
> of operands...
>
Yes, thats why CCP had to trim down its def->use chains to just the
variables it cared about rather than all of them. It was a large memory
savings to do that.
> > The uses/defs are all cached.
>
> Don't caches take space?
>
Yeah, but thats already consumed. If you are suggesting we replace our
entire operand implemenation with FUDs, I'm pretty sure thats not going
to happen :-)
So our operand cache takes up space. Adding def->use chains takes up
even more space
> > And if you do need it over a chain of optimizations, do it once, and
> > then keep the info up to date/. You'll be a lot better off I think
>
> Isn't that the whole idea?
>
Yes, but I am suggesting we dont keep it around all the time since many
optimizations do not need it, and it costs memory. The ones that do need
it can build that info for the variables it cares about more
efficiently. CCP cares about a different set of variables than the loop
optimizer likely does.
Andrew