[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