mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2025-01-18 13:34:04 +00:00
9d2ed8e632
argument is non-null, pass it along to PHITranslateSubExpr so that it can prefer using existing values that dominate the PredBB, instead of just blindly picking the first equivalent value that it finds on a uselist. Also when the DominatorTree is specified, have PHITranslateValue filter out any result that does not dominate the PredBB. This is basically just refactoring the check that used to be in GetAvailablePHITranslatedSubExpr and also in GVN. Despite my initial expectations, this change does not affect the results of GVN for any testcases that I could find, but it should help compile time. Before this change, if PHITranslateSubExpr picked a value that does not dominate, PHITranslateWithInsertion would then insert a new value, which GVN would later determine to be redundant and would replace. By picking a good value to begin with, we save GVN the extra work of inserting and then replacing a new value. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97010 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.
//===---------------------------------------------------------------------===//