[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