[PATCH] D34385: [ImplicitNullChecks] Uphold an invariant in areMemoryOpsAliased
Serguei Katkov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Jun 19 22:53:51 PDT 2017
skatkov created this revision.
Right now areMemoryOpsAliased has an assertion justified as:
// MMO1 should have a value due it comes from operation we'd like to use
// as implicit null check.
assert(MMO1->getValue() && "MMO1 should have a Value!");
However, it is possible for that invariant to not be upheld in the
following situation (conceptually):
Null check %RAX
NotNullSucc:
%RAX = LEA %RSP, 16 // I0
%RDX = MOV64rm %RAX // I1
With the current code, we will have an early exit from
ImplicitNullChecks::isSuitableMemoryOp on I0 with SR_Unsuitable.
However, I1 will look plausible (since it loads from %RAX) and
will go ahead and call areMemoryOpsAliased(I1, I0). This will cause
us to fail the assert mentioned above since I1 does not load from an
IR level value and thus is allowed to have a non-Value base address.
The fix is to return SR_Impossible whenever we see an unsuitable
instruction overwrite PointerReg. This would guarantee that when we
call areMemoryOpsAliased, we're guaranteed to be looking at an
instruction that loads from or stores to an IR level value.
https://reviews.llvm.org/D34385
Files:
lib/CodeGen/ImplicitNullChecks.cpp
test/CodeGen/X86/non-value-mem-operand.mir
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D34385.103154.patch
Type: text/x-patch
Size: 17872 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170620/b63b0c59/attachment.bin>
More information about the llvm-commits
mailing list