On 30/04/2024 13:43, Jan Hubicka wrote:
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.
Actually, we don't have the true/false, but maybe the CFG recording can
be extended to include it, along with unconditional, is_fake, is_throw
etc., looks like there's room in the bitset. Finding the right edge is
easy because we have both the source and destination.
I'll check out if storing the true/false flag is simple and submit a patch.
Honza
Richard.
Thanks,
Jørgen
