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

[Dan Gohman via Phabricator via llvm-commits]

sunfish added a comment.

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.



================
Comment at: lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:5667
+    // Discard annotate attributes, assumptions, and artificial side-effects.
     return nullptr;
 
----------------
hfinkel wrote:
> sunfish wrote:
> > efriedma wrote:
> > > Why is it safe to drop the llvm.sideeffect call in SelectionDAG?
> > Just that SelectionDAG and CodeGen after it don't currently have any optimizations that rely on forward-progress guarantees, and probably won't add them. Those kinds of optimizations are the optimizer's job.
> > 
> > If there's any situation where there's an actual loop in the user code that is at all possible to eliminate, it's always better to find a way to have the optimizer do it, because that's an enabling optimization that will make other parts of the optimizer more powerful.
> I'm not sure the situation is that straightforward. We can also use this information to assume things about the behavior of expressions that determine loop strip counts, and we might want to do that later in the pipeline too.
> 
> We don't have anything that does that now, however, so we'll just need to preserve this somehow if need be.
It wouldn't be complicated to add an ISD::SIDEEFFECT and TargetOpcode::SIDEEFFECT and carry them all the way through codegen, and to fix the various places that they pessimize, if it turns out to be important.


Repository:
  rL LLVM

https://reviews.llvm.org/D38336