mirror of
https://github.com/llvm/llvm-project.git
synced 2025-05-05 14:06:08 +00:00
c41404a090
virtual interface on AliasAnalysis only deals with ModRef information. This interface was both computing memory locations by using TLI and other tricks to estimate the size of memory referenced by an operand, and computing ModRef information through similar investigations. This change narrows the scope of the virtual interface on AliasAnalysis slightly. Note that all of this code could live in BasicAA, and be done with a single investigation of the argument, if it weren't for the fact that the generic code in AliasAnalysis::getModRefBehavior for a callsite calls into the virtual aspect of (now) getArgModRefInfo. But this patch's arrangement seems a not terrible way to go for now. The other interesting wrinkle is how we could reasonably extend LLVM with support for custom memory location sizes and mod/ref behavior for library routines. After discussions with Hal on the review, the conclusion is that this would be best done by fleshing out the much desired support for extensions to TLI, and support these types of queries in that interface where we would likely be doing other library API recognition and analysis. Differential Revision: http://reviews.llvm.org/D10259 llvm-svn: 239884
Analysis Opportunities:
//===---------------------------------------------------------------------===//
In test/Transforms/LoopStrengthReduce/quadradic-exit-value.ll, the
ScalarEvolution expression for %r is this:
{1,+,3,+,2}<loop>
Outside the loop, this could be evaluated simply as (%n * %n), however
ScalarEvolution currently evaluates it as
(-2 + (2 * (trunc i65 (((zext i64 (-2 + %n) to i65) * (zext i64 (-1 + %n) to i65)) /u 2) to i64)) + (3 * %n))
In addition to being much more complicated, it involves i65 arithmetic,
which is very inefficient when expanded into code.
//===---------------------------------------------------------------------===//
In formatValue in test/CodeGen/X86/lsr-delayed-fold.ll,
ScalarEvolution is forming this expression:
((trunc i64 (-1 * %arg5) to i32) + (trunc i64 %arg5 to i32) + (-1 * (trunc i64 undef to i32)))
This could be folded to
(-1 * (trunc i64 undef to i32))
//===---------------------------------------------------------------------===//