Re: [tree-ssa] Lazy updating of stmt operands

[law at redhat dot com]

In message <1071525828.3257.1907.camel@p4>, Andrew MacLeod writes:
 >I guess it depends on how hard it is to find out. CCP goes and
 >determines an initial value for every variable. If the initial value is
 >something we already know cannot be a constant, we dont include it. THis
 >was very significant for virtual PHI nodes, since that means they never
 >got included,so we save a lot on those 2000 element phi nodes.
Right.

 >> I am not sure whether this is not saving on the wrong place.  You need
 >> some 12 bytes per operand (perhaps 8, with some extra effort), which
 >> seems incomparable to the amount of memory we waste everywhere else.
 >
 >It may be suprising, but you end up with PHIs which have 2000 operands,
 >and they reach 40 different places.. it does both consume a reasonable
 >amount of memory, and it takes measurable amounts of time to build the
 >additional information.
 >
 >To take a step back, this was quite a while ago before we did some of
 >our recent wonderful memory work. I will look at it again, and see if
 >its still nasty. You can give it a quick try yourself. the function
 >  need_imm_uses_for
 >in tree-ssa-ccp, change it to return true all the time, and see what the
 >compilation time difference for gerald testcase is. It use to increase
 >CCPs time as well as overall time noticably. Perhaps it doesn't now, I
 >havent tried it lately.
I doubt Zdenek will see a huge change -- largely because we factor the
computed gotos which were causing the PHI explosions.  But the underlying
concept of filtering out variables we do not care about (because we know
they are varying) is still wise.

And to a much lesser extent, part of the problem is that we create way
too many virtual operands because of our lousy aliasing.

jeff