Re: Tree-SSA self checking infrastructure

[law at redhat dot com]

In message <20031119182545.GN16923@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
 >I think we can move PHI checks to verify_ssa.  Does this look plausible?
That would be perfect as long as we don't call verify_ssa directly from
verify_cfg or cleanup_cfg.

 >>  >   b) verifying gimple types is almost impossible now.  The reason is
 >>  >   ssa_useless_type_conversion.  Where we got about the plans to make it
 >>  >   transitive and symteric?
 >> I can't be transitive and symmetric.  Fundamentally it can't be that way.
 >> (think about casting of function pointers).
 >
 >Is there any way to check that given random gimple expr resulting from
 >sequence of substitutions is still having matching types in this relaxed
 >way?
I haven't thought a lot about it.    I've got a TODO based on one of
your earlier messages to look at some stuff, but haven't gotten around
to it.

For non-pointer integral types the rules are trivial (and in fact they are
symmetric and transitive -- it's only pointers that can't be made
transitive and symmetric).

The nop conversion is consider useless if

  same types

  or

  same type main variant

  or

  same modes && same signedness && same precision


The problem you're trying to solve isn't necessarily solvable because
you don't know what the expression's original type was.  ie, given an
expr, you know its current type, but you don't know the original type
of the expression.




 >>  >   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.

But as I've harped on, type conversions are killing us in terms of optimization
so we keep looking at ways to either eliminate the NOPs or find ways to
allow them in certain expressions.

We don't have a serious long term strategy for dealing with nops.


 >> 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.

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.

Jeff