[PATCH] D50558: [MustExecute] Fix algorithmic bug in isGuaranteedToExecute. PR38514
Sanjoy Das via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sat Aug 18 11:58:59 PDT 2018
sanjoy added a comment.
In https://reviews.llvm.org/D50558#1203623, @mkazantsev wrote:
> Actually this logic is accidentally correct right now because `isGuaranteedToTransferExecutionToSuccessor` thinks that volatile loads don't transfer execution to successors (which was under discurrion and probably needs removed) and MustExecute is super-conservative about such instructions in non-header blocks (see https://reviews.llvm.org/D50377). When MustThrow analysis becomes less restrictive, this problem becomes a real one and we hoist sdiv from such examples despite the fact that they are no longer "finite" according to C++ specification.
Sorry, I wasn't clear. I meant to say that transforming
while (true) {
if (<unknown condition>) {
int c = 1 / divisor;
break;
}
}
to
int c = 1 / divisor;
while (true) {
if (<unknown condition>) {
break;
}
}
is correct for C++ (because non-side effecting infloops are UB) and that I believe your change will "regress" this optimization (since LLVM will not longer hoist the division). Though I guess if no-one complains about it in a couple of days then we're fine?? :)
What you're saying, that it would be a bug even for C++ if LLVM hoisted the divide from
while (true) {
<volatile load>
if (<unknown condition>) {
int c = 1 / divisor;
break;
}
}
is correct, but not quite what I'm trying to say.
Also, given what you said about `isGuaranteedToTransferExecutionToSuccessor`, perhaps we can close llvm.org/PR24078?
Repository:
rL LLVM
https://reviews.llvm.org/D50558
More information about the llvm-commits
mailing list