This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Tree-SSA self checking infrastructure
> 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.
How can one cleanup the CFG without updating the underlying SSA?
Honza
>
> > 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