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] How to increase PHI capacity?


On Mon, 2003-08-04 at 15:22, Steven Bosscher wrote:

> Well, wouldn't that would break stuff all over if things are pointing to
> the PHI?
> 
No, it shouldn't.  Why do you think it would?  You're not changing the
address of the PHI node itself, only its vector of arguments.  We don't
(shouldn't) cache the addresses of each element in the array.

> I would prefer a varray, but that is not practical either, because
> varray.h would have to know more about "struct phi_arg_d", but including
> tree.h in every file that includes varray.h isn't my idea of a clean
> solution.  And using a varray of pointers to phi_arg_d, instead of an
> array of structs, well, overhead....
> 
Agreed.


> But, I would expect that some optimizations would make cleanup
> opportunities like this available (DCE when purging blocks, CCP when
> killing branches, ...).  In particular, merging small blocks appears to
> be something that could be done quite often.
> 
> And having fewer blocks to deal with in subsequent passes is a good
> thing.
> 
Yeah, that's why I think we should probably support jumps-to-jumps
optimization while in SSA form.

> > At some point, however, we should probably just give up and re-build the
> > whole thing from scratch.
> 
> You mean rebuild the SSA representation?  Wouldn't that be more
> expensive than properly updating?
> 
Depends how messed up the SSA form is.  But in general, we need to
support incremental updates and have some heuristic cost function that
determines when to give up.


Diego.


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