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

[Dan Gohman via Phabricator via llvm-commits]

sunfish added inline comments.


================
Comment at: docs/LangRef.rst:14208
+has externally observable side effects and therefore may not be deleted
+or reordered past other externally observable side effects.
+
----------------
efriedma wrote:
> A language that needs these is going to be inserting a lot of them; assuming a language doesn't have goto, I think the frontend needs to insert one at the beginning of every function and every loop.  Is there some rule for coalescing and/or eliminating llvm.sideeffect calls which aren't necessary?
Eliminating requires seeing a `volatile` access, or similar, nearby, because LLVM doesn't know when calls are guaranteed to perform side effects. Coalescing two @llvm.sideeffect calls would be straightforward. I haven't implemented these yet because if there's already a volatile access or an @llvm.sideeffect call nearby, deleting another `@llvm.sideeffect` call doesn't usually make much difference (to eg. functionattrs).


================
Comment at: lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:5667
+    // Discard annotate attributes, assumptions, and artificial side-effects.
     return nullptr;
 
----------------
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.


Repository:
  rL LLVM

https://reviews.llvm.org/D38336