[PATCH] D36392: [ImplicitNullCheck] Fix the bug when dependent instruction accesses memory
Sanjoy Das via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 7 09:36:45 PDT 2017
sanjoy accepted this revision.
sanjoy added a comment.
This revision is now accepted and ready to land.
lgtm with minor comments
================
Comment at: lib/CodeGen/ImplicitNullChecks.cpp:315
+ AliasResult AR = areMemoryOpsAliased(MI, PrevMI);
+ if (AR != AR_NoAlias)
+ return AR;
----------------
IIUC this isn't optimal -- we can early return with `AR_MayAlias` when processing further would have given us `AR_WillAliasEverything`.
================
Comment at: lib/CodeGen/ImplicitNullChecks.cpp:322
+ImplicitNullChecks::AliasResult
+ImplicitNullChecks::areMemoryOpsAliased(MachineInstr &MI,
MachineInstr *PrevMI) {
----------------
Minor, but I'd be consistent here and either take both as refs or pointers.
================
Comment at: lib/CodeGen/ImplicitNullChecks.cpp:343
+ if (const PseudoSourceValue *PSV2 = MMO2->getPseudoValue()) {
+ if (PSV1) {
+ // Special case, both are pseudo values.
----------------
There are too many `continue`s and `return`s here -- do you mind splitting out a `mayAlias(MachineMemOperand *, MachineMemOperand *)` helper?
================
Comment at: lib/CodeGen/ImplicitNullChecks.cpp:369
+ }
+ // Both MMO1 and MMO2 has value represented by LLVM IR.
llvm::AliasResult AAResult = AA->alias(
----------------
s/has value/have values/
================
Comment at: lib/CodeGen/ImplicitNullChecks.cpp:470
+ // Verify that DependenceMI does not alias with any instructions seen so far.
+ if (DependenceMI->mayLoadOrStore())
+ if (areMemoryOpsAliased(*DependenceMI, { InstsSeenSoFar.begin(),
----------------
I vaguely remember that originally we did not allow the dependence MI to touch memory. Do you know when this changed (or am I misremembering)?
https://reviews.llvm.org/D36392
More information about the llvm-commits
mailing list