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

Daniel Berlin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 28 22:37:59 PDT 2017


dberlin added a comment.

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

> In https://reviews.llvm.org/D38336#882873, @dberlin wrote:
>
> > 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 supports C++, ADCE needs to preserve calls to a library I/O functions, volatile operations, thread synchronizations, and atomic operations, and calls to functions which may perform any of these. Whatever it does to handle those should handle llvm.sideeffect as well.


This seems pretty incongruous to me with your answers to my earlier questions, so i feel like i'm missing something.
Those mechanisms keep loops that are useful alive. They are definition of what makes a loop useful in the first place.
You said that llvm.sideeffect, by itself, should not be a reason to keep it alive if say, you can prove it finite or unreachable.  It's only there to keep otherwise infinite empty loops alive.
But if you use the same mechanisms, it will always keep the loop alive, no matter what. Even if it's finite, etc.
In particular, those mechanisms are used to mark things that are still not able to be eliminated, for example,  despite the loop being provably finite and otherwise empty.

So if llvm.sideeffect is not like those things, and does not mean the loop should stay alive if it's provably finite and otherwise empty (For example), i fail to see how the existence of those mechanisms helps.


Repository:
  rL LLVM

https://reviews.llvm.org/D38336





More information about the llvm-commits mailing list