Re: SSA operand interface change proposal

[Andrew MacLeod <amacleod at redhat dot com>]

On Tue, 2004-06-15 at 23:38, Zdenek Dvorak wrote:
> Hello,
> 
> > I think the changes are pretty minimal considering what we are trying to
> > do.
> > 
> > The problem with lazy updating is PHI nodes. We dont have that facility,
> > and although we could probably provide it, I doubt anyone wants to have
> > to call get_stmt_operands() on phi nodes before using them.
> >
> > This is my 4th cut at the problem. The second cut was using the lazy
> > updating as you suggest, but I ran into some implementaion issues wrt
> > PHI nodes. I'd like to see all operands treated consistantly.
> 
> in the patch for the problem I posted in December
> (http://gcc.gnu.org/ml/gcc/2003-12/msg00676.html) I solved this problem
> simply by changing phi node arguments through replace_phi_arg_num
> function consistently, which turned out to be trivial.  So I think that
> the problem is not that critical, and possibly the operand
> representation changes you propose could be considered as an independent
> patch.

It is an independant patch, and its a prerequisit to the immediate uses
stuff as far as I am concerned.  I want to get it checked in before even
attempting the remainder of the immediate_uses work. 

The difference is that we are (will be) no longer maintaining
immediate_use information externally in a table. It will instead be
integrated directly into the stmt operands where it belongs. This
appears to make a dramatic difference on the memory hit and locality of
the information versus having it in a table.

I personally think these operand changes should have been done a long
time ago. Uncontrolled chaotic access to the operands is generally a bad
idea IMHO. especially when it doesnt cost you anything to have some
control. What Im doing is adding some consistancy to the way we
manipulate operands in all stmts.  Once we have that consistancy, it
becomes much easier to do things like immediate_uses in a sane way.

Note that even with this, you can still go off and do whatever you want
to the trees, you just have to make sure you call modify_stmt() and
get_stmt_operands() on it, and you work with trees instead of the
operand cache. (Someday, the operand cache may in fact replace the trees
in some stmts, but thats a different conversation :-)

Im running mainline bootstrap/regression on x86 right now. Assuming it
goes OK overnight I'll post it along with an LNO friendly version in the
morning.  Took longer than I expected since my branch didnt have the
MUST_DEF stuff, so I had to redo a lot of changes because the patches
didnt apply very well.

Andrew