Re: [ tree-ssa] PRE problem

[Daniel Berlin <dberlin at dberlin dot org>]

On Feb 20, 2004, at 10:25 PM, law@redhat.com wrote:

> In message <E1008D69-6417-11D8-B39D-000A95DA505C@dberlin.org>, Daniel 
> Berlin wr
> ites:
> > >   3. There is no need for this code to signal a failure to its
> > >      callers.  A failure for this code is worthy of an abort
> > >      given the clarifications we've done for copies appearing
> > >      in the IL.
> >
> > For insertion, yes. For verification, i'm not so sure.
> Maybe I'm missing something about the verification step because I
> still don't what circumstances in generate_expr_as_of_bb should
> cause a failure.

> Fundamentally what this routine is doing is taking an expression's form
> in block X and rewriting the expression in whatever form it would have 
> in
> block Y (where Y is a predecessor of X).

correct.

> That means examining the PHI nodes in X which are connected to Y and
> replacing the PHI_RESULT with the appropriate PHI_ARG.
correct.

> As we're both aware, this is fundamentally different than copy 
> propagation.
yes

> As we've discussed, if the PHI_RESULT and PHI_ARG have non-null 
> differing
> tags then that is a catastrophic failure and we ought to abort rather
> than signaling a failure to the caller.
True enough.

> The test for the objects being used in abnormal PHIs should have 
> already
> been taken care of by other code in tree-ssa-pre if I read it 
> correctly,
> so that check ought to be pointless in generate_expr_as_of_bb.

Yup
> If the result is a DECL_HARD_REGISTER, then we're safe as well -- we're
> not replacing an assignment of a DECL_HARD_REGISTER value with a
> non-DECL_HARD_REGISTER value.  Quite the opposite in fact.

Right.


> > >   4. We need a function which updates the annotations and only aborts
> > >      if there is an inconsistency in the memory tag info.
> >
> > Right. That's what insertion wants.  verification just wants the
> > versions to be correct. :)
> But even at the verification step, you have to have consistent tag
> information or get_stmt_operands is going to fail miserably.
True enough.
I guess we should just abort.
> ode

> But the nature of requiring the RHS/LHS to have the same tags means 
> that
> they are the same for *any* copy between the RHS & LHS (assuming both 
> are
> nonzero).

Right.

> The "optimistic" setting of the memory tag in the verification step
> merely does one step of that full propagation.  It can not change
> the final answer.
Right.


> [ Note for Jan who loves building consistency checkers -- this would
>   probably be a useful thing to check... ]
>
>
> My wife is calling me for dinner, I'll respond to the rest later...
> Hopefully the rest doesn't invalidate what I've stated above :-)

It shouldn't. It's just an explanation of how the algorithm works, but 
you seem to have figured it out :)
>