Re: [tree-ssa] some manual store sinking for tree-dfa

[Andrew MacLeod <amacleod at redhat dot com>]

On Tue, 2003-12-09 at 09:03, Jan Hubicka wrote:
> > On Mon, 2003-12-08 at 19:08, Steven Bosscher wrote:
> > > Hi,
> > > 
> > > Honza noted that, surprisingly, tree-dfa.c:add_vdef is a bottleneck.
> > > This patch help a bit, but not enough.  Walking over two potentially
> > > big varrays, bah...
> > > 
> > > BTW Without this patch we could sink the store to source, but I've
> > > verified that we don't do that.  Is store sinking implemented?
> > > 
> > > Bootstrapped & tested on i686-pc-linux-gnu.  OK, or is this going
> > > away when Andrew is done with his new voperands data structs?
> > > 
> > 
> > > 
> > > 	* tree-dfa.c (add_vdef): Only store `source' if we've found it.
> > > 
> > 
> > 
> > Hmm.  Its not completely going away, but it is being reworked
> > significantly. I will rework it a bit more carefully based on those
> > observations, and at the very least, incorporate your changes.  I'll see
> > if I can speed it up even more than that tho.
> 
> To be more specific, I've measured 3.7% of time spent there in
> unoptimized enable checking compiler.  Most of the time is accounted to
> verify_ssa that makes verify_ssa looks worse than it really is (as the
> time would be spent later in subsequent pass using stmt_operands).
> Still good motivation to get verify_ssa faster (it is 5% on Geralds
> testcase currently)
> 

Measuring with ENABLE_CHECKING enabled and no optimization can be
misleading :-)

however
> In the case the loop looking for duplicates is major problem, we can
> simply reserve flag in tree node for this that is set each time we
> insert new vop and reset of all vops once we are done.

The bottle neck must be originating in add_stmt_operand():

              /* If the variable is also an alias tag, add a virtual operand
                for it, otherwise we will miss representing references to the
                members of the variable's alias set.  This fixes the bug in
                gcc.c-torture/execute/20020503-1.c.  */
              if (v_ann->is_alias_tag)
                add_vdef (var, stmt, prev_vops);

              for (i = 0; i < VARRAY_ACTIVE_SIZE (aliases); i++)
                add_vdef (VARRAY_TREE (aliases, i), stmt, prev_vops);


Thats the only place its called more than once per operand, so if the
alias set is large, it would result in a lot of calls.

I've also already split the building of operands into 2 peices. First
you build the operands vectors, then you associate it to the stmt. This
simplified a lot of things. Adding the flag would be pretty straight
forward and localized to one place. (We now have a "we're done" place to
clear the flag out.)

I'll add it once everything is working. Im "enjoying" getting everything
working in the presence of all the GGCing between phases now :-)

Andrew