[LLVMdev] BackedgeTakenCount calculation for fortran loops and DragonEgg gfortran-4.6

Marcello Maggioni hayarms at gmail.com
Wed Feb 8 16:14:43 PST 2012


This is the .ll for that graph (attached). I think I understand what
you are saying.
This particular testcase returns CNC not because the exit block
doesn't have a unique predecessor, but because the unique predecessor
(the inner loop block) has a successor that is inside the loop (in
this case itself, because it's the inner loop block).

That doesn't change, anyway, the assuption that this condition ( an
exit block that jumps to a block with an unconditional jump that jumps
to the loop header and that has as unique predecessor the exit block)
is equivalent to jumping directly to the loop header.

2012/2/9 Nick Lewycky <nlewycky at google.com>:
> On 8 February 2012 15:50, Marcello Maggioni <hayarms at gmail.com> wrote:
>>
>> Well, it wasn't intended as a "real" patch to be included , but more
>> as a "proof of concept" for a solution. Do you think it is a valid
>> solution and I'm correct in my assumption? If so then I'll clean up
>> the patch and attach a testcase for inclusion.
>
>
> I'm not sure -- when I tried to track the IR in your screenshot through the
> code in SCEV I came up with a completely different reason it would return
> the CNC than the one you gave in your email. It would really help to have a
> testcase in .ll format.
>
> Nick
>
>>
>> Thanks!
>>
>> Marcello
>>
>> 2012/2/9 Nick Lewycky <nlewycky at google.com>:
>> > Your patch should include a testcase, see test/Analysis/ScalarEvolution
>> > for
>> > examples. "BranchInst* " should be "BranchInst *". You should have
>> > spaces
>> > after the // in your comments. One of the comment lines isn't indented
>> > properly.
>> >
>> > Nick
>> >
>> > On 8 February 2012 12:05, Marcello Maggioni <hayarms at gmail.com> wrote:
>> >>
>> >> Attached
>> >>
>> >> 2012/2/8 Marcello Maggioni <hayarms at gmail.com>:
>> >> > Mmm, sorry, the patch I posted crashes if ExitBr is null (which it
>> >> > may
>> >> > be ...) , this one should be ok (and passess all the ScalarEvolution
>> >> > tests in LLVM):
>> >> >
>> >> > diff --git a/lib/Analysis/ScalarEvolution.cpp
>> >> > b/lib/Analysis/ScalarEvolution.cpp
>> >> > index daf7742..b10fab2 100644
>> >> > --- a/lib/Analysis/ScalarEvolution.cpp
>> >> > +++ b/lib/Analysis/ScalarEvolution.cpp
>> >> > @@ -4293,9 +4293,15 @@ ScalarEvolution::ComputeExitLimit(const Loop
>> >> > *L, BasicBlock *ExitingBlock) {
>> >> >   //
>> >> >   // FIXME: we should be able to handle switch instructions (with a
>> >> > single exit)
>> >> >   BranchInst *ExitBr =
>> >> > dyn_cast<BranchInst>(ExitingBlock->getTerminator());
>> >> > +
>> >> >   if (ExitBr == 0) return getCouldNotCompute();
>> >> >   assert(ExitBr->isConditional() && "If unconditional, it can't be in
>> >> > loop!");
>> >> >
>> >> > +  BranchInst* BrFirstSucc = dyn_cast<BranchInst>(ExitBr->
>> >> > +
>> >> >  getSuccessor(0)->getTerminator());
>> >> > +  BranchInst* BrSecondSucc = dyn_cast<BranchInst>(ExitBr->
>> >> > +
>> >> >  getSuccessor(1)->getTerminator());
>> >> > +
>> >> >   // At this point, we know we have a conditional branch that
>> >> > determines whether
>> >> >   // the loop is exited.  However, we don't know if the branch is
>> >> > executed each
>> >> >   // time through the loop.  If not, then the execution count of the
>> >> > branch will
>> >> > @@ -4316,10 +4322,23 @@ ScalarEvolution::ComputeExitLimit(const Loop
>> >> > *L, BasicBlock *ExitingBlock) {
>> >> >   if (ExitBr->getSuccessor(0) != L->getHeader() &&
>> >> >       ExitBr->getSuccessor(1) != L->getHeader() &&
>> >> >       ExitBr->getParent() != L->getHeader()) {
>> >> > -    // The simple checks failed, try climbing the unique predecessor
>> >> > chain
>> >> > -    // up to the header.
>> >> > +
>> >> >     bool Ok = false;
>> >> > -    for (BasicBlock *BB = ExitBr->getParent(); BB; ) {
>> >> > +    //Check if the one of the successor of the exit branch has the
>> >> > is a
>> >> > block
>> >> > +    //that has only one predecessor and has an unconditional branch
>> >> > to
>> >> > the
>> >> > +    //loop header
>> >> > +    if (BrFirstSucc && BrFirstSucc->isUnconditional() &&
>> >> > +        BrFirstSucc->getSuccessor(0) == L->getHeader() &&
>> >> > +        BrFirstSucc->getParent()->getUniquePredecessor())
>> >> > +      Ok = true;
>> >> > +    if (BrSecondSucc && BrSecondSucc->isUnconditional() &&
>> >> > +        BrSecondSucc->getSuccessor(0) == L->getHeader() &&
>> >> > +        BrSecondSucc->getParent()->getUniquePredecessor())
>> >> > +      Ok = true;
>> >> > +     // The simple checks failed, try climbing the unique
>> >> > predecessor
>> >> > chain
>> >> > +    // up to the header.
>> >> > +
>> >> > +    for (BasicBlock *BB = ExitBr->getParent(); BB && !Ok; ) {
>> >> >       BasicBlock *Pred = BB->getUniquePredecessor();
>> >> >       if (!Pred)
>> >> >         return getCouldNotCompute();
>> >> >
>> >> > anyway, this patch is only "a concept" of what I'm talking about.
>> >> >
>> >> > PS=Sorry for the bad english in the previous post :p
>> >> >
>> >> > 2012/2/8 Marcello Maggioni <hayarms at gmail.com>:
>> >> >> Hello, I'm finding problems with BackEdgeTaken count calculation in
>> >> >> even simple fortran loops with gfortran-4.6 + DragonEgg 3.0.
>> >> >>
>> >> >> Even for simple double loops like this one:
>> >> >>
>> >> >>       program test2
>> >> >>       integer i,j,k
>> >> >>       dimension k(100,100)
>> >> >>       do j=1,100
>> >> >>        do i=1,100
>> >> >>         k(i,j) = i
>> >> >>        enddo
>> >> >>       enddo
>> >> >>       write(*,*) k(1,30)
>> >> >>       end
>> >> >>
>> >> >> make the ScalarEvolution engine return "CouldNotCompute" even for
>> >> >> the
>> >> >> outer loop (the inner loop is fine).
>> >> >>
>> >> >> You can find a screenshot of the translation of this loop here (with
>> >> >> -view-cfg Polly version):
>> >> >> http://i.imgur.com/Jyaqd.png
>> >> >>
>> >> >> The problem seems to be the fact that the ScalarEvolution can't
>> >> >> consider the outer loop exit branch instruction as the trivial case
>> >> >> (where one of the successors of the exit block is the loop header or
>> >> >> the exit block is the loop header itself) because of the (strange?)
>> >> >> loop shape (the exit block instead of jumping to the header of the
>> >> >> loop jumps instead to another block that increments the induction
>> >> >> variable and has an unconditional branch to the loop header) and so
>> >> >> starts backtracking the predecessors of the of the exit block and
>> >> >> stops when it reaches the inner loop that has a block without a
>> >> >> unique
>> >> >> predecessor.
>> >> >>
>> >> >> What do you think about this problem? This makes , for example,
>> >> >> difficult analyzing even simple fortran loops with Polly .
>> >> >> I believe the case portrayed in the picture is the same to the
>> >> >> trivial
>> >> >> case (because the exit block jumps to a block with an unconditional
>> >> >> jump to the header of the loop), am I right?
>> >> >>
>> >> >> I've written this little patch that adds this case to the trivial
>> >> >> case
>> >> >> :
>> >> >>
>> >> >> diff --git a/lib/Analysis/ScalarEvolution.cpp
>> >> >> b/lib/Analysis/ScalarEvolution.cpp
>> >> >> index daf7742..fcbaffe 100644
>> >> >> --- a/lib/Analysis/ScalarEvolution.cpp
>> >> >> +++ b/lib/Analysis/ScalarEvolution.cpp
>> >> >> @@ -4293,6 +4293,11 @@ ScalarEvolution::ComputeExitLimit(const Loop
>> >> >> *L, BasicBlock *ExitingBlock) {
>> >> >>   //
>> >> >>   // FIXME: we should be able to handle switch instructions (with a
>> >> >> single exit)
>> >> >>   BranchInst *ExitBr =
>> >> >> dyn_cast<BranchInst>(ExitingBlock->getTerminator());
>> >> >> +  BranchInst* BrFirstSucc = dyn_cast<BranchInst>(ExitBr->
>> >> >> +
>> >> >>  getSuccessor(0)->getTerminator());
>> >> >> +  BranchInst* BrSecondSucc = dyn_cast<BranchInst>(ExitBr->
>> >> >> +
>> >> >>  getSuccessor(1)->getTerminator());
>> >> >> +
>> >> >>   if (ExitBr == 0) return getCouldNotCompute();
>> >> >>   assert(ExitBr->isConditional() && "If unconditional, it can't be
>> >> >> in
>> >> >> loop!");
>> >> >>
>> >> >> @@ -4315,8 +4320,12 @@ ScalarEvolution::ComputeExitLimit(const Loop
>> >> >> *L, BasicBlock *ExitingBlock) {
>> >> >>   //
>> >> >>   if (ExitBr->getSuccessor(0) != L->getHeader() &&
>> >> >>       ExitBr->getSuccessor(1) != L->getHeader() &&
>> >> >> -      ExitBr->getParent() != L->getHeader()) {
>> >> >> -    // The simple checks failed, try climbing the unique
>> >> >> predecessor
>> >> >> chain
>> >> >> +      ExitBr->getParent() != L->getHeader() &&
>> >> >> +      !((BrFirstSucc && BrFirstSucc->isUnconditional() &&
>> >> >> +         BrFirstSucc->getSuccessor(0) == L->getHeader()) ||
>> >> >> +        (BrSecondSucc && BrSecondSucc->isUnconditional() &&
>> >> >> +         BrSecondSucc->getSuccessor(0) == L->getHeader())) ) {
>> >> >> +     // The simple checks failed, try climbing the unique
>> >> >> predecessor
>> >> >> chain
>> >> >>     // up to the header.
>> >> >>     bool Ok = false;
>> >> >>     for (BasicBlock *BB = ExitBr->getParent(); BB; ) {
>> >> >>
>> >> >> what do you think about this? There is a better solution to the
>> >> >> problem? Is the compiler itself broken?
>> >> >>
>> >> >> Thank you
>> >> >>
>> >> >> Marcello
>> >>
>> >> _______________________________________________
>> >> LLVM Developers mailing list
>> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >>
>> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.preopt.ll
Type: application/octet-stream
Size: 3666 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120209/6b490e74/attachment.obj>


More information about the llvm-dev mailing list