[PATCH] D75238: [DAGCombine] Fix alias analysis for unaligned accesses

Nick Desaulniers via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 27 15:34:10 PST 2020


nickdesaulniers added inline comments.


================
Comment at: llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:21131
+  int64_t Size0 = MUC0.NumBytes.hasValue() ? *MUC0.NumBytes : -1;
+  int64_t Size1 = MUC1.NumBytes.hasValue() ? *MUC1.NumBytes : -1;
   if (OrigAlignment0 == OrigAlignment1 && SrcValOffset0 != SrcValOffset1 &&
----------------
The hunk you modify on L21156-L21157 highlights was looks like maybe a pre-existing incorrect usage of `Optional::operator*`; there's no check that `MUC0.NumBytes` `hasValue` before making use of the value (which may not exist).  In particular, I'm concerned what the value of `-1` might do in those expressions.

Or you could do:

```
auto& Size0 = MUC0.NumBytes;
auto& Size1 = MUC1.NumBytes;

if ( ... && Size0.hasValue() && Size0.hasValue() && ...)
  foo(*Size0, *Size1)
```
Though I'm not sure whether the lower hunk should have a guard as well vs use a value of `0`.  Using `-1` for a possible value of the `Optional<int64_t>` might be problematic, though I assume the number of bytes in a "memory use characteristic" is unlikely. (I wish the "LLVM Programmers Manual" had a section on `llvm::Optional`). So maybe it's ok to keep as is, but then I really think the lower hunk should also have some kind of guard.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75238/new/

https://reviews.llvm.org/D75238





More information about the llvm-commits mailing list