Hopelessly broken loop_father, loop_depth

[Steven Bosscher <stevenb dot gcc at gmail dot com>]

Hello Richi,

After a frustrating few days of trying to figure out what *I* was
doing wrong trying to speed up rewrite_into_loop_closed_ssa(), I
finally gave up and looked at the rest of GCC. One wouldn't expect
anything to be very broken in an unpatched tree, after all, but the
kind of failures I was seeing just couldn't be explained by any fault
of my own.

Such as loop_depth(bb->loop_father) != bb->loop_depth.
Or even worse, flow_bb_inside_loop_p (bb->loop_father, bb) is false.

This looks all related to maintaining loops in the GIMPLE optimizers,
but quite frankly, I don't really understand how the loop updating API
is supposed to work, and I'm not even sure whether bb->loop_depth and
bb->loop_father are supposed to be accurate at all times (other places
in the compiler appear to rely on this, but it's still not documented,
and I've spent enough time on this already when it's probably fixed in
a jiffy by you ;-).

Could you please have a look at this breakage? (And please, document
the loop stuff and also all the SSA name changes ASAP instead of
postponing it to stage3 or later!)

Lots of test cases fail with the attached patch. As a starting point
for you, I'll mention 920723-1.c compiled with -O1
-ftree-unswitch-loops. This gives:

920723-1.c: In function 'f':
920723-1.c:33:1: error: bb 15 has father loop 3, should be loop 2
 }
 ^
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1
920723-1.c:33:1: error: bb 8 has father loop 3, should be loop 2
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1
920723-1.c:33:1: error: bb 13 has father loop 5, should be loop 2
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1
920723-1.c:33:1: error: bb 16 has father loop 4, should be loop 2
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1
920723-1.c:33:1: error: bb 17 has father loop 5, should be loop 2
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1
920723-1.c:33:1: error: bb 5 has father loop 5, should be loop 2
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1
920723-1.c:33:1: error: bb 7 has father loop 3, should be loop 2
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1
920723-1.c:33:1: error: bb 6 has father loop 4, should be loop 2
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1
920723-1.c:33:1: error: bb 13 has father loop 5, should be loop 3
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2
920723-1.c:33:1: error: bb 16 has father loop 4, should be loop 3
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2
920723-1.c:33:1: error: bb 17 has father loop 5, should be loop 3
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2
920723-1.c:33:1: error: bb 5 has father loop 5, should be loop 3
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2
920723-1.c:33:1: error: bb 6 has father loop 4, should be loop 3
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2
920723-1.c:33:1: error: bb 5 has father loop 5, should be loop 4
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 3
920723-1.c:33:1: error: bb 13 has father loop 5, should be loop 4
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 3
920723-1.c:33:1: error: bb 17 has father loop 5, should be loop 4
920723-1.c:33:1: error: bb 1 has loop depth 0, should be 3
920723-1.c:33:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1583
Please submit a full bug report, etc.

BTW, it's quite annoying that loop_depth(loop_p) returns "unsigned
int", but bb->loop_depth is just "int". Is loop_depth<0 used as a
special case? If so, then I think loop_depth(loop_p) should be changed
to return "int", otherwise bb->loop_depth should be made an "unsigned
int". What do you think about this?

Ciao!
Steven

Attachment: tighten_loop_verifier.diff
Description: Binary data