This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Maintaining/representing def-use/use-def information
- From: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, Chris Lattner <sabre at nondot dot org>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Tue, 16 Dec 2003 20:58:53 -0700
- Subject: Re: [tree-ssa] Maintaining/representing def-use/use-def information
- Reply-to: law at redhat dot com
In message <20031215205553.GA24610@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
>Hello,
>
>> Ultimately, I dont see much difference other than implementation
>> details...
>
>... and about three times more memory spent, I would estimate. For a
>single assignment statement, we have:
>
>1) The var_decl node
Which was already going to exist anyawy.
>2) The ssa name
Which are shared among every reference to the name version #.
>3) modify_expr
Yes. Particularly since we can't share them among lexically idential
statements.
>4) operation_expr
Yes. Particularly since we can't share these either.
>+ pointers to link them together, versus
>
>1) single entity containing just the operation code and two pointers to
> the arguments (+additional information like type, etc).
And as I stated in a message yesterday, Andrew's recent work actually
takes us one step closer to this model. Is it there yet? Certainly not,
but I can see a day in the future (after initial integration with the
mainline) where we'd want to look at using Andrew's work as the basis
for all the SSA optimizers and ban looking at the underlying trees. Hell,
the underlying trees might simply be able to disappear.
jeff