[PATCH] D74691: [Attributor] add some pattern to containsCycle

Hideto Ueno via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Feb 16 21:43:00 PST 2020


uenoku added a comment.

In D74691#1878429 <https://reviews.llvm.org/D74691#1878429>, @jdoerfert wrote:

> In D74691#1878377 <https://reviews.llvm.org/D74691#1878377>, @uenoku wrote:
>
> > In D74691#1878376 <https://reviews.llvm.org/D74691#1878376>, @jdoerfert wrote:
> >
> > > In D74691#1878373 <https://reviews.llvm.org/D74691#1878373>, @uenoku wrote:
> > >
> > > > I'm not sure whether we can say if all the loops given by `LoopInfo` have a max trip count and all the callees are `willreturn`, then we can guarantee the termination of that function.
> > >
> > >
> > > We can not. But if all cycles in the CFG are loops recognized by loop info and they have a max trip count we are good (in this part), I think.
> >
> >
> > How can we confirm all cycles in the CFG are recognized actually by loop info? Is there a simple way?
>
>
> What @omarahmed does here should work (with the fixes I mentioned). As before, we identify all cycles via the depth-first search and the visited set. If a cycles is found we did bail before but now we ask LI & SE instead. If they say we found a proper loop header of a loop with a bounded trip count we can ignore that cycles and continue exploring. Do you think there is a problem with that logic?


I might misunderstand the logic. This seems fine. I also think @baziotis's idea works well.


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