[PATCH] D38662: [BasicAA] Support arbitrary pointer sizes (and fix an overflow bug)

[Hal Finkel via Phabricator via llvm-commits]

hfinkel created this revision.
Herald added a subscriber: mcrosier.

Motivated by the discussion in https://reviews.llvm.org/D38499, this patch updates BasicAA to support arbitrary pointer sizes by switching most remaining non-APInt calculations to use APInt. The size of these APInts is set to the maximum pointer size (maximum over all address spaces described by the data layout string).

Most of this translation is straightforward (although needs to be checked carefully), but this patch contains a fix for a bug that revealed itself during this translation process. In order for test/Analysis/BasicAA/gep-and-alias.ll to pass, which is run with 32-bit pointers, the intermediate calculations must be performed using 64-bit integers. This is because, as noted in the patch, when GetLinearExpression decomposes an expression into C1*V+C2, and we then multiply this by Scale, and distribute, to get (C1*Scale)*V + C2*Scale, it can be the case that, even through C1*V+C2 does not overflow for relevant values of V, (C2*Scale) can overflow. If this happens, later logic will draw invalid conclusions from the (base) offset value. Thus, when initially applying the APInt conversion, because the maximum pointer size in this test is 32 bits, it started failing. Suspicious, I created a 64-bit version of this test (included here), and that failed (miscompiled) on trunk for a similar reason (the multiplication can overflow).

After fixing this overflow bug, the first test case (at least) in Analysis/BasicAA/q.bad.ll started failing. This is also a 32-bit test, and was relying on having 64-bit intermediate values to have BasicAA return an accurate result. In order to fix this problem, and because I believe that it is not uncommon to use i64 indexing expressions in 32-bit code (especially portable code using int64_t), it seems reasonable to always use at least 64-bit integers. In this way, we won't regress our analysis capabilities (and there's a command-line option added, so experimenting with this should be easy).

This should also fix the problem motivating https://reviews.llvm.org/D38499. Michael, can you please test this, improve the test case from https://reviews.llvm.org/D38499 so it can included, and generate additional test cases if possible for extra-large pointers.

Please review.


https://reviews.llvm.org/D38662

Files:
  include/llvm/Analysis/BasicAliasAnalysis.h
  include/llvm/IR/DataLayout.h
  lib/Analysis/BasicAliasAnalysis.cpp
  lib/IR/DataLayout.cpp
  test/Analysis/BasicAA/gep-and-alias-64.ll
  test/Analysis/BasicAA/gep-and-alias.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D38662.118126.patch
Type: text/x-patch
Size: 18996 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171007/7adfab37/attachment.bin>