mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2025-01-21 03:32:21 +00:00
f9cb030376
in the dependence test, we used to discard some information that the delinearization provides: the size of the innermost dimension of an array, i.e., the size of scalars stored in the array, and the remainder of the delinearization that provides the offset from which the array reads start, i.e., the base address of the array. To avoid losing this data in the rest of the data dependence analysis, the fix is to multiply the access function in the last delinearized dimension by its size, effectively making the size of the last dimension to always be in bytes, and then add the remainder of delinearization to the last subscript, effectively making the last subscript start at the base address of the array. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201867 91177308-0d34-0410-b5e6-96231b3b80d8
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))
//===---------------------------------------------------------------------===//