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] reaching def. question


On Wed, 2004-03-17 at 11:43, Chris Lattner wrote:
> 
> Diego Novillo wrote:
> > I had originally implemented an SSA form that did not need an out-of-ssa
> > pass.  You could just drop the SSA_NAME wrappers because no overlapping
> > live ranges would occur.  Other compilers (IBM's and SGI's) do the same,
> > but to date I have not found a convincing explanation favouring one
> > design over the other.
> 
> At least in the case of SGI, I understood that they implemented it that
> way for two reasons: 1. avoid an increase in register pressure, and 2.
> work better with the legacy compiler optimizations they already had.
> 
> #2 certainly makes a lot of sense, and this decision also made their
> implementation of (e.g.) SSAPRE simpler, but I have a hard time buying
> argument #1.
> 
> For the record, LLVM allows arbitrary overlapping of virtual registers.
> We don't even have "versions" or an "out of SSA renamer".  In my
> *extremely biased* opinion, this makes it a lot easier to reason about
> what code does, e.g., making it trivial to answer Devang's original
> question.
> 

There has certainly been discussion of moving/delaying the ssa->normal
phase right up to the rtl generation stage, at which point all the
ssa_versions become distinct registers in rtl, and hopefully lots of
coalescing through PHI nodes to avoid copies. At that point, SSA->normal
becomes just a PHI node coalescer. I think that boils down to the same
thing you are talking about. We currently have to go back into non-ssa
form in order for the current expanders to work properly. That will not
be a permanent limitation. 

I also think at some point we need to stop taking all versions of an SSA
variable out of, and back into SSA, and focus just on the ones we need.
Things like copyrenaming which changes the base variable of an
ssa_version could wreak havoc on such activity. 

Andrew


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