mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2025-01-14 16:33:28 +00:00
af7a28939e
if we don't have an address expression available in a predecessor, then model this as the value being clobbered at the end of the pred block instead of being modeled as a complete phi translation failure. This is important for PRE of loads because we want to see that the load is available in all but this predecessor, and complete phi translation failure results in not getting any information about predecessors. This doesn't do anything until I renable code insertion since PRE now sees that it is available in all but one predecessors, but can't insert the addressing in the predecessor that is missing it to eliminate the redundancy. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@90037 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.
//===---------------------------------------------------------------------===//