[PATCH] D30667: GVNHoist: handle basic blocks with UnreachableInst
Daniel Berlin via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Mar 13 14:09:18 PDT 2017
dberlin added a comment.
In https://reviews.llvm.org/D30667#699749, @efriedma wrote:
> > Staring at other places it is used, it looks like it would also think it okay to propagate various non-nullness attributes, etc past unreachable.
>
> Propagate them to where? unreachable doesn't have any successors. This only makes sense if you connect the unreachable to the function's exit, or something like that.
Backwards:
for (Instruction &I : Entry) {
if (auto CS = CallSite(&I)) {
if (auto *CalledFunc = CS.getCalledFunction()) {
for (auto &CSArg : CalledFunc->args()) {
if (!CSArg.hasNonNullAttr())
continue;
// If the non-null callsite argument operand is an argument to 'F'
// (the caller) and the call is guaranteed to execute, then the value
// must be non-null throughout 'F'.
auto *FArg = dyn_cast<Argument>(CS.getArgOperand(CSArg.getArgNo()));
if (FArg && !FArg->hasNonNullAttr()) {
FArg->addAttr(Attribute::NonNull);
Changed = true;
}
}
}
}
if (!isGuaranteedToTransferExecutionToSuccessor(&I))
break;
}
IE the case i'm thinking of, but not sure if we care about:
If there are calls in the entry block, and the entry block ends in unreachable, we have the property that the unreachable means we can assume the block doesn't execute.
But we are still using the calls in the block pretending that they are guaranteed to execute.
:)
IE I was told the semantics of unreachable say that if we are guaranteed to hit the unreachable, along a given codepath, we can assume that code path cannot execute.
So should we be propagating non-nullness based on them?
Repository:
rL LLVM
https://reviews.llvm.org/D30667
More information about the llvm-commits
mailing list