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

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

Maybe we should do this in follow-up, but I'd also like to see some general text added to the LangRef about the semantics of loops (that makes reference to this intrinsic). Maybe we can say something like:

  Loops that contains no calls that access inaccessible memory, perform no atomic or volatile memory access, nor otherwise synchronizes with other threads, are assumed to eventually terminate. If the source-level language has well-defined infinite loops, the LLVM IR representation of such loops should contain at least one call to `@llvm.sideeffect`.

We'll then need to update Clang to insert this intrinsic into loops (in C) that have a constant controlling condition (per C11 6.8.5p6).



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


Repository:
  rL LLVM

https://reviews.llvm.org/D38336