> > The problem is testing. If gcc would re-number the basic blocks then > > tests comparing hard-coded test paths would break, even though the path > > coverage itself would be just fine (and presumably the change to the > > basic block indices), which would add an unreasonable maintenance > > burden. If anything, it feels very fragile to write tests against the > > basic block indices. > > Problematic is usually when early canonicalization changes the > direction of a branch which affects the block IDs of the true/false > destinations (and their downstream blocks).
I think we can renumber Bbs sequentially before profile generation (or maybe we do already). But indeed the CfG may change with time. > > > On the other hand, if it can be expected that the same code should > > always yield the same CFG, the same BBs, and the same BB indices then I > > would happily test against them. I suppose this makes the basic blocks > > basically a public interface, which granted feels odd. > > > > If you have any good idea on how to test paths in a robust way please > > let me know. > > Is there enough info to print a path like the following? > > path not covered: t.c:2(true) t.c:4(false) t.c:11(true) ... > > instead of printing (condition destination?) block IDs? This was my first idea too. Thre can be multiple BBs per line but you can print both BB ID and source file nameand ignore the BB ID for testsuite pruposes. Honza > > Richard. > > > > > Thanks, > > Jørgen
