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: birthpoints in rtl.


On Fri, Feb 29, 2008 at 20:39, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:

>  I personally dislike the fact that the middle end keeps the phi's separate.

Six of one, half a dozen of the other.  If you put the PHIs in the IL
stream, then you need to be careful about not moving anything before
or in between them.  They also have different semantic properties:
they execute all in parallel and so the result of one PHI cannot be
used as an argument in another PHI in the same block.  Things like SSA
propagation need to treat them differently, etc.

Some things would potentially become easier, while others become more
difficult.  It would probably a good experiment to run on a branch
some time.

>  Then my plan is to "adapt" as much of the tree ssa code (there is no
>  reason for me to write dominance frontier code for the 4 time from
>  scratch)

You don't need to.  Dominance information is completely IL
independent.  It only needs the CFG.

>  [ ... ] and can just adapt the ssa stack based renaming algorithm to build
>  the chains rather than rename the vars.  I have no idea if wolfe ever
>  figured this part out or not.

Yes, he did.  That's the main point behind my proposal.

Both FUD chains and rewriting SSA operate in *exactly* the same way,
we do not need two renaming algorithms in tree-into-ssa.c.  The only
difference between FUD chains and rewriting SSA is that the former
does not modify the statement, it merely rewrites the VDEF/VUSE
operands (thus creating the SSA web).  If you adapt the algorithm to
simply rewrite the DF chains, you will be set.

FUD chains are never part of the IL, so by converting the UD links to
factored UD links in the DF data structure, you should be able to get
all the benefit of the sparser representation.

What if you treated subregs as total writes (like we do arrays) and
libcalls as clobbering points?  Though I guess that may not be
sufficient.


Diego.


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