[PATCH] D74691: [Attributor] Detect possibly unbounded cycles in functions

omar ahmed via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 25 16:17:46 PST 2020


omarahmed added a comment.

In D74691#1892476 <https://reviews.llvm.org/D74691#1892476>, @baziotis wrote:

> In D74691#1892447 <https://reviews.llvm.org/D74691#1892447>, @omarahmed wrote:
>
> > I am sorry but I can't get what the test that the approach of moving on the SCCs fails in as I have tried to test it a bit with tests like that and printed the SCCs that it gets
> >
> > https://i.imgur.com/fpZhpST.png
> >  1 - entry
> >  2- condition - body
> >  3- return
> >  4 - l4
> >
> > https://i.imgur.com/UJJ3aH0.png
> >  1- entry
> >  2- l1 - l2 - l3 - l4 - l5
> >  3- return
> >  4- l6 - l7 - l8
> >
> > https://i.imgur.com/92NS6rp.png
> >  1- entry
> >  2- l1 - l2 - l3 - l4 - l5 - l6 - l7
> >  3- return
> >
> > and in all of them it reached the cycle and outputs that the loop does not have a max trip count
>
>
> Sorry, but I didn't understand your comment very much. The code //I// wrote certainly can't detect max trip count.
>  It only correctly (hopefully) finds if there's a cycle or not. The second modification also found the size of the cycle.
>  Did //you// write any code that used `LI` ? In that case, as I said earlier, I have some algorithm in mind that uses `LI`
>  but I can't seem to be able to get `LI` (i.e. it's always `nullptr`). So, probably the same will be true for you
>  even if your code is correct. Hopefully we can get an answer about why that happens.


I mean the code you suggested that loops on SCCs using SCCiter then it appeared that tarjan only detects maximal SCCs, the one that uses tarjan algorithm :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74691/new/

https://reviews.llvm.org/D74691





More information about the llvm-commits mailing list