This is the mail archive of the 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?

Op ma 04-08-2003, om 20:33 schreef Diego Novillo:
> On Mon, 2003-08-04 at 11:15, Steven Bosscher wrote:
> > There doesn't seem to be an easy way to increase the capacity of a PHI,
> > at least I can't find it.  Is this just missing, or have my thoughts
> > completely misguided me here?
> > 
> No, there isn't.  It's a fixed-size array set at PHI creation time.  You
> would have to implement a new function that calls ggc_realloc to resize
> the array.

Well, wouldn't that would break stuff all over if things are pointing to
the PHI?

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....

>   Also remember to update the immediate dominator information
> in each basic block.

Obviously.  I haven't figured out yet, but I suppose I can just mimic

> I'm wondering if it wouldn't be easier to do this optimization *before*
> converting the function into SSA.  After all, this optimization doesn't
> need dataflow information.  OTOH, we may need to run it after other
> optimizations, so I guess we might as well support this.

True.  Dataflow only complicates things here.

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

> 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?


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