aboutsummaryrefslogtreecommitdiff
path: root/clang/unittests/Frontend/CompilerInvocationTest.cpp
diff options
context:
space:
mode:
authorNikita Popov <nikita.ppv@gmail.com>2020-12-01 18:06:37 +0100
committerNikita Popov <nikita.ppv@gmail.com>2020-12-11 18:45:53 +0100
commit8b1c4e310c2f9686cad925ad81d8e2be10a1ef3c (patch)
treea4e0840ba41758c69639daebc790d2f879abc675 /clang/unittests/Frontend/CompilerInvocationTest.cpp
parenta5f5612263ca650ae0aa433539278c2d5f567cf8 (diff)
downloadllvm-8b1c4e310c2f9686cad925ad81d8e2be10a1ef3c.zip
llvm-8b1c4e310c2f9686cad925ad81d8e2be10a1ef3c.tar.gz
llvm-8b1c4e310c2f9686cad925ad81d8e2be10a1ef3c.tar.bz2
[BasicAA] Handle two unknown sizes for GEPs
If we have two unknown sizes and one GEP operand and one non-GEP operand, then we currently simply return MayAlias. The comment says we can't do anything useful ... but we can! We can still check that the underlying objects are different (and do so for the GEP-GEP case). To reduce the compile-time impact, this a) checks this early, before doing the relatively expensive GEP decomposition that will not be used and b) doesn't do the check if the other operand is a phi or select. In that case, the phi/select will already recurse, so this would just do two slightly different recursive walks that arrive at the same roots. Compile-time is still a bit of a mixed bag: https://llvm-compile-time-tracker.com/compare.php?from=624af932a808b363a888139beca49f57313d9a3b&to=845356e14adbe651a553ed11318ddb5e79a24bcd&stat=instructions On average this is a small improvement, but sqlite with ThinLTO has a 0.5% regression (lencod has a 1% improvement). The BasicAA test case checks this by using two memsets with unknown size. However, the more interesting case where this is useful is the LoopVectorize test case, as analysis of accesses in loops tends to always us unknown sizes. Differential Revision: https://reviews.llvm.org/D92401
Diffstat (limited to 'clang/unittests/Frontend/CompilerInvocationTest.cpp')
0 files changed, 0 insertions, 0 deletions