This makes our poison value analysis a little smarter.
Yeah, but I didn't want to write it that way -- IMO it is only "incidental" that mayHaveSideEffects and what I'm computing here are the same implementation. IOW, the predicate in the two cases (mayHaveSideEffects vs. "guaranteed to transfer control flow to successor") are quite different, even if they have the same implementation.
This seems unfortunate given that, as I understand it, we then can't compile C11 correctly:
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.