Re: [patch] Rewrite building of virtual operands

[Andrew MacLeod <amacleod at redhat dot com>]

On Mon, 2006-02-27 at 18:00 +0100, Zdenek Dvorak wrote:

> At the moment, tree-ssa-opfinalize.h forces us to build virtual operands
> in a way that is similar to that for virtual operands, i.e., to
> accumulate them in a vector.  However, we know that for each DECL, there may be
> only one virtual operand, and we want them to be sorted by decl_uid in
> the list of virtual operands of the statement; achieving this is a bit
> clumsy with the current representation -- bitmap is the appropriate type
> for representing the object that satisfies these two properties.

Its done that way for a reason. I spent a *lot* of time tuning this
code. This lies underneath almost everything ssa does, so minor changes
can impact the speed of all ssa passes, especially in the more
pathological cases. By using an sbitmap, you are going to have a lot of
additional allocates and frees for the sbitmap's... the in_list bits of
the annotations are already allocated and available. I agree they are a
touch awkward, but they are faster.   Did you try to time this patch?
its bound to slow down the operand cache.  I got about a 20% slowdown on
cplusplus_grammer.cc , less on .c files and I'm sure its much worse on
the nasty ones that I didn't get around to tracking down. (the ones in
bugzilla where large percentages of compile time is operand processing)

> 
> This patch makes us use bitmaps for accumulating virtual operands of a
> statement.  This prevents us from using tree-ssa-opfinalize.h, however,
> the code duplication shows up to be surprisingly small.  Nevertheless,
> the code is overall simpler (some pre- and post-processing of virtual
> operands that was necessary before is not needed). This representation
> also enables us to solve the problem discussed in
> http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01245.html and followups
> (turning maydefs into mustdefs) in a natural way.


Im not sure why you think everything needs to be changed in order to do
what you want. I mentioned a fairly simply way of doing it that wouldn't
cost much time, nor require reimplementing anything.

If you want to remove tree-ssa-opfinalize.h, I'm certainly fine with
that. Simply expand it to the 10 functions and put it directly into
tree-ssa-operands.c.  Once thats is done, its very little work to add
the required checks of the maydef list to finalize_ssa_v_must_def_ops().

And if you don't want to do that, the following small patch (although
not tested thoroughly) will move a maydef to a mustdef without rewriting
anything.  does this accomplish what you want adequately? Its much less
intrusive.

Of course, it all goes out the window anyway when Diego's memory ssa is
ready... all the virtual operands will be handed in the ssa-renamer
rather than the cache, and unlike mustdefs, maydefs will have varying
numbers of operands.
 
Andrew

Attachment: D
Description: Text document