[PATCH] D65718: [LangRef] Document forward-progress requirement

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Aug 4 10:36:39 PDT 2019


jdoerfert added a comment.

In D65718#1613967 <https://reviews.llvm.org/D65718#1613967>, @nikic wrote:

> In D65718#1613947 <https://reviews.llvm.org/D65718#1613947>, @lebedev.ri wrote:
>
> > I was under impression that the exact opposite was the status,
> >  even if it wasn't consistently followed everywhere.
>
>
> That was also my own impression as well, but @jdoerfert and @Meinersbur argued that this is the the current consensus. I would be //very// happy if this isn't the case. We should clarify this one way or another in LangRef though, to avoid future confusion on this point.


My argument comes from the current behavior:
We delete non-side-effect loops and recursion.

> For what it's worth, actually using `llvm.sideeffect` for this purpose results in pretty catastrophic regressions right now. I think things wouldn't be quite as bad if it was only needed to control loops, but the need to also account for recursion means that `llvm.sideeffect` ends up literally everywhere. If this is indeed the way forward, we should probably add a sideeffect coalescing pass and see if that makes this at least somewhat viable.

We could probably improve the handling of `llvm.sideeffect` in certain situations. Especially once we propagate information about accessed (inaccessible) memory locations (D60077 <https://reviews.llvm.org/D60077> needs rebase though), we should see better results.
I hope we will then have interactions only with other "inaccessible" intrinsics which should not be too bad.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65718





More information about the llvm-commits mailing list