[PATCH] D38336: Add an @llvm.sideeffect intrinsic

[Daniel Berlin via Phabricator via llvm-commits]

dberlin added a comment.

In https://reviews.llvm.org/D38336#882864, @sunfish wrote:

> In https://reviews.llvm.org/D38336#882813, @dberlin wrote:
>
> > Is literally the only purpose to handle infinite loops?
> >  If so, please tighten up the description a bit.
> >  (Right now "indicate that the loop shouldn't be optimized away even if it's an infinite
> >  loop with no other side effects."  would cover unreachable loops, etc).
>
>
> Another potential use was mentioned here <http://lists.llvm.org/pipermail/llvm-dev/2015-July/088114.html>.


One reason i ask is because ADCE/etc wouldn't even see it. they won't process the block in such a case.
Hence, if the intrinsic relies on always being looked at and then deciding to keep everything containing it, i'd be opposed (since that adds O(N) walks to everything :P).
Right now, it doesn't sound like that's the case.

(If it was, i'd request we either build an analysis like assume analysis, or circularly link these into a separate instruction list in basic blocks so you can tell in O(1) whether they are there)

>> Do you expect it to keep provably finite loops that have it alive.
>>  IE a loop where we can prove the backedge is not taken?
> 
> No; a backedge can still be folded away in the normal ways. The `llvm.sideeffect` call would remain, no longer needed, but not invalid. If it were important, we could add code to remove it in that case, but the patch here doesn't have that.

SGTM


Repository:
  rL LLVM

https://reviews.llvm.org/D38336