Re: Tree-SSA self checking infrastructure

[law@redhat.com]

In message <20031121013047.GF341@atrey.karlin.mff.cuni.cz>, Jan Hubicka writes:
 >> In message <20031119174450.GI11681@kam.mff.cuni.cz>, Jan Hubicka writes:
 >>  >1) Gimple testing
 >>  >   a) verifying that each stmt is gimple is trivial, will hook it into
 >>  >   verify_flow_info, or shal I invent verify_stmt/verify_stmts?
 >> Please do not hook this into verify_flow_info.  Testing that the statements
 >> are gimple has absolutely nothing to do with verification that the CFG
 >> is correct.
 >> 
 >> In fact, one could argue that some of the stuff in verify_flow_info really
 >> belongs elsewhere.  Consider this situation (which I'm already bumping into
 >).
 >> 
 >>   I want to thread a jump to a block with a PHI node.  So I update the CFG
 >>   and the block with the PHI node now has an additional edge.
 >> 
 >>   Then I want to cleanup the CFG.
 >> 
 >>   Then I want to rebuild the dominator tree.
 >> 
 >>   Then I want to re-rename those objects which were affected by the
 >>   CFG changes.
 >Are you sure this scheme is safe?
 >CFG cleanup updates SSA form and expect it to be valid on the input.
I'm pretty sure.  However, long term cleanup_cfg shouldn't be looking at
the SSA graph in any meaningful way.

 >This looks like wrong interface and it seems to me that cfg_cleanup
 >should actually call verify_ssa... 
No, it means cleanup_cfg needs to be re-thought, particularly those
routines which examine/modify the SSA graph.

 > Why can't you do re-renaming before cleaning?
You can do renaming before cleaning, but that's totally silly.  You've
just munged the CFG is lots of interesting ways.  Blocks are going to
go away,  conditionals turn into direct jumps, etc.  All this affects 
renaming.

Jeff