[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