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: Jeff Law <law at redhat dot com>
- Cc: Chris Lattner <sabre at nondot dot org>, Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: 15 Dec 2003 22:24:01 -0500
- Subject: Re: [tree-ssa] Lazy updating of stmt operands
- References: <200312152336.hBFNaA8g019471@speedy.slc.redhat.com>
On Mon, 2003-12-15 at 18:36, law@redhat.com wrote:
> In message <1071323157.3257.138.camel@p4>, Andrew MacLeod writes:
> >The Cache isnt something we're trying to work around. Thats there to
> >prevent us from having to muck around in trees looking for things which
> >are operands. The stmt is in the form of trees, our "cache" is the
> >equivilent of your instruction. It consists of the operands plus looking
> >at the tree code(s) of the stmt.
> >
> >So we have 1 word for each operand. It points to the SSA_NAME in the
> >stmt tree which represents that ssa version.
> >
> >As far as Im concerned, we're not working around anything. Everything
> >works just fine. IF someone wants/needs the def->use inforation, it can
> >be built today. What we dont have is the ability to keep it up to date
> >for some period of time, simply because we've never needed it. If the
> >time comes that we do need it, it is not hard to add.
> In fact, we could even ponder the idea of what we now know as the operand
> cache morphing into a lighter-weight IL at some point in the future.
>
Indeed, it is the core of what we deal with.
Andrew