1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-24 03:33:20 +01:00
llvm-mirror/test/Analysis
Hal Finkel 88d49a9216 [BasicAA] Support arbitrary pointer sizes (and fix an overflow bug)
Motivated by the discussion in 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, 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).

As pointed out by Eli during the review, there are other potential overflow
conditions that this patch does not address. Fixing those is left to follow-up
work.

Patch by me with contributions from Michael Ferguson (mferguson@cray.com).

Differential Revision: https://reviews.llvm.org/D38662

llvm-svn: 350220
2019-01-02 16:28:09 +00:00
..
AliasSet
AssumptionCache
BasicAA [BasicAA] Support arbitrary pointer sizes (and fix an overflow bug) 2019-01-02 16:28:09 +00:00
BlockFrequencyInfo
BranchProbabilityInfo
CallGraph
CFLAliasAnalysis
ConstantFolding [ConstantFolding] Consolidate and extend bitcount intrinsic tests; NFC 2018-12-20 19:46:52 +00:00
CostModel [CostModel][X86] Don't count 2 shuffles on the last level of a pairwise arithmetic or min/max reduction 2018-12-13 19:08:10 +00:00
Delinearization
DemandedBits Reapply "[DemandedBits][BDCE] Support vectors of integers" 2018-12-07 15:38:13 +00:00
DependenceAnalysis
DivergenceAnalysis [DA] GPUDivergenceAnalysis for unstructured GPU kernels 2018-11-30 22:55:20 +00:00
DominanceFrontier
Dominators
GlobalsModRef
IVUsers
LazyCallGraph
LazyValueAnalysis [LVI] run transfer function for binary operator even when the RHS isn't a constant 2018-11-21 05:24:12 +00:00
LegacyDivergenceAnalysis
Lint
LoopAccessAnalysis [LV] Avoid vectorizing unsafe dependencies in uniform address 2018-11-19 15:39:59 +00:00
LoopInfo Introduce llvm.loop.parallel_accesses and llvm.access.group metadata. 2018-12-20 04:58:07 +00:00
MemoryDependenceAnalysis
MemorySSA
MustExecute
PhiValues
PostDominators
ProfileSummary
RegionInfo
ScalarEvolution [test] Fix ScalarEvolution test to allow __func__ with prototype 2018-12-02 16:49:28 +00:00
ScopedNoAliasAA
StackSafetyAnalysis [stack-safety] Inter-Procedural Analysis implementation 2018-11-26 23:05:58 +00:00
TypeBasedAliasAnalysis
ValueTracking
alias-analysis-uses.ll