[LLVMdev] Little bug in LoopInfo after Rotate?

[Julio]

Hello, I have two for loops (one inside the other), that after indvars,
looprotate, etc. (the important here is the loop rotate), is similar to this
(I've stripped the real operations):

define i32 @f() nounwind  {
entry:
    br label %bb1

bb1:        ; preds = %bb3, %bb1, %entry
    %i.0.reg2mem.0.ph = phi i32 [ 0, %entry ], [ %i.0.reg2mem.0.ph, %bb1 ],
[ %indvar.next9, %bb3 ]        ; <i32> [#uses=4]
    %j.0.reg2mem.0 = phi i32 [ 0, %entry ], [ %indvar.next, %bb1 ], [ 0,
%bb3 ]        ; <i32> [#uses=3]
    %indvar.next = add i32 %j.0.reg2mem.0, 1        ; <i32> [#uses=2]
    %exitcond = icmp eq i32 %indvar.next, 16        ; <i1> [#uses=1]
    br i1 %exitcond, label %bb3, label %bb1

bb3:        ; preds = %bb1
    %indvar.next9 = add i32 %i.0.reg2mem.0.ph, 1        ; <i32> [#uses=2]
    %exitcond10 = icmp eq i32 %indvar.next9, 32        ; <i1> [#uses=1]
    br i1 %exitcond10, label %bb6, label %bb1

bb6:        ; preds = %bb3
    ret i32 0
}

LoopInfo says: Loop Containing:  %bb1, %bb3. Only detects the outer loop

By the way, if I separate the header of the outer loop, like:

define i32 @f() nounwind  {
entry:
    br label %bb0

bb0:        ; preds = %entry, %bb3
    %i.0.reg2mem.0.ph = phi i32 [ 0, %entry ], [ %indvar.next9, %bb3 ]
    ; <i32> [#uses=4]
    br label %bb1

bb1:        ; preds = %bb1, %bb0
    %j.0.reg2mem.0 = phi i32 [ 0, %bb0 ], [ %indvar.next, %bb1 ]        ;
<i32> [#uses=3]
    %indvar.next = add i32 %j.0.reg2mem.0, 1        ; <i32> [#uses=2]
    %exitcond = icmp eq i32 %indvar.next, 16        ; <i1> [#uses=1]
    br i1 %exitcond, label %bb3, label %bb1

bb3:        ; preds = %bb1
    %indvar.next9 = add i32 %i.0.reg2mem.0.ph, 1        ; <i32> [#uses=2]
    %exitcond10 = icmp eq i32 %indvar.next9, 32        ; <i1> [#uses=1]
    br i1 %exitcond10, label %bb6, label %bb0

bb6:        ; preds = %bb3
    ret i32 0
}

LoopInfo:
Loop Containing:  %bb0, %bb3, %bb1
    Loop Containing:  %bb1

I would need to operate in the two loops in rotated form. It can be
considered a bug or I have to introduce manually the header (or modify
myself the ConsiderForLoop to my particular problem)?

Thanks.
Julio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080713/cfacf586/attachment.html>