Re: Tree-SSA self checking infrastructure

[Jan Hubicka <hubicka at ucw dot cz>]

Hi,
I will give deeper tought to the pointer types.  About the other
topics...
>  >>  >   c) I commonly got hit by the feature of gimple allowing almost
>  >>  >   arbitrarily complex constant operands.  What about restricting it
>  >>  >   into primitive constants +
>  >>  >   (plus_expr (nop_expr (addr_exr )) (integer_cst) as the most complex
>  >>  >   form?
>  >> This has been a subject of great debate.  I don't think we have a solid
>  >> answer on where a NOP_EXPR might appear.
>  >
>  >It seems to always appear inside the PLUS expr.  It seems like natural
>  >choice.
>  >Without that we should have to make recursive walk each time we are
>  >looking for ADDR_EXPR.
> The problem is once you allow it in a PLUS (or anywhere else other than the
> RHS of a MODIFY_EXPR) that you've changed the gimple grammar and you have
> to account for that change in the gimple grammar.  ie, you can no longer
> make assumptions that the first argument of a PLUS is a gimple variable.
> It might now be a NOP.
> 
> That's the fundamental issue -- it changes the grammar.

I don't mean allowing some extra.  I am seeing these NOP_EXPRs inside
ADDR_EXPRs all the time so I assumed they are valid.
OK, now I see it is bug, so I will try to fix it (unless Richard already
did so).
>  >> Having a verification step that you don't rename an already renamed 
>  >> variable after a certain point (after the dominator based jump threading)
>  >> would be good.
>  >Many passes seems to rewrite variables efter dominater pass.  What to
>  >do?
> They rewrite newly exposed variables.  ie, they're rewriting VAR_DECLs,
> PARM_DECLs, that were addressable, but due to optimizations they are no
> longer addressable and thus can be put into SSA form and optimized.

This brings me into questions about my tail call updating code.
Perhaps I need to re-do SSA form on call cobbered variables after
removing the call?
> 
> The exception is the dominator based jump threader where we do rerewrite
> existing SSA_NAMEs.  In that case we know there are no overlaps as we have
> done no optimizations which could have created an overlap.

I see.  It would be nice to drop a comment somewhere in tree-optimize.c
clarifying what can be renamed when.

Honza
> 
> Jeff
>