[PATCH] D19210: Teach poison value tracking that certain calls always terminate

Hal Finkel via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 26 10:17:52 PDT 2016


hfinkel added a subscriber: hfinkel.

================
Comment at: lib/Analysis/ValueTracking.cpp:3288
@@ +3287,3 @@
+    // not contain side effects.  As far as I can tell, this isn't a new
+    // assumption (e.g. we will DCE readnone and readonly calls).
+    return CS.doesNotThrow() && CS.onlyReadsMemory();
----------------
sanjoy wrote:
> broune wrote:
> > This seems unfortunate given that, as I understand it, we then can't compile C11 correctly:
> > 
> >   http://stackoverflow.com/questions/16436237/is-while1-undefined-behavior-in-c
> > 
> > Go ahead and submit this if you're sure that the consensus is that this is how LLVM ought to behave. I'd be more comfortable if the langref stated that infinite side-effect free loops are not allowed, but I couldn't find anything about that in there.
> I'm going to look at http://stackoverflow.com/questions/16436237/is-while1-undefined-behavior-in-c , but assuming that's accurate (i.e. `while (1);` is well defined) I'll redact this patch.  It's not really an option (IMO) to miscompile C11. :)
As I understand it, LLVM is not really self-consistent on this point. As you point out, we we will DCE readnone and readonly calls. We should be, however, because we have frontends for languages with well-defined infinite loops (Java?, and apparently C11), and those without well-defined infinite loops (C++), and we'd like to do the best job on all of them. I think we need a new function-level attribute that controls whether we get to assume that loops terminate, and then we can make a consistent decision everywhere.


http://reviews.llvm.org/D19210





More information about the llvm-commits mailing list