[llvm-commits] [llvm] r142731 - in /llvm/trunk: lib/Analysis/ScalarEvolution.cpp test/Analysis/ScalarEvolution/load.ll

[Eli Friedman]

On Mon, Oct 24, 2011 at 11:29 AM, Nick Lewycky <nlewycky at google.com> wrote:
> On 23 October 2011 07:15, Duncan Sands <baldrick at free.fr> wrote:
>>
>> Hi Nick,
>>
>> > -  if (const CmpInst *CI = dyn_cast<CmpInst>(I))
>> > +  if (CmpInst *CI = dyn_cast<CmpInst>(I))
>> >       return ConstantFoldCompareInstOperands(CI->getPredicate(),
>> > Operands[0],
>> >                                              Operands[1], TD);
>> > +  if (LoadInst *LI = dyn_cast<LoadInst>(I)) {
>> > +    if (!LI->isVolatile())
>> > +      return ConstantFoldLoadFromConstPtr(Operands[0], TD);
>> > +  }
>> >     return ConstantFoldInstOperands(I->getOpcode(), I->getType(),
>> > Operands, TD);
>>
>> maybe you could use instsimplify here?  It does constant folding and more
>> besides.  It can break LCSSA form, so y so,
>> check out the loop transform users of instsimplify to seou may need to
>> check for that (ife how).
>
> As far as I can see, LCSSA isn't documented and I don't understand it well
> enough to know whether I'm preserving it or breaking it etc. I know it
> involves creating 1-operand PHI nodes in strategic places and that's about
> it.

>From LCSSA.cpp:

// This pass transforms loops by placing phi nodes at the end of the loops for
// all values that are live across the loop boundary.  For example, it turns
// the left into the right code:
//
// for (...)                for (...)
//   if (c)                   if (c)
//     X1 = ...                 X1 = ...
//   else                     else
//     X2 = ...                 X2 = ...
//   X3 = phi(X1, X2)         X3 = phi(X1, X2)
// ... = X3 + 4             X4 = phi(X3)
//                          ... = X4 + 4
//
// This is still valid LLVM; the extra phi nodes are purely redundant, and will
// be trivially eliminated by InstCombine.  The major benefit of this
// transformation is that it makes many other loop optimizations, such as
// LoopUnswitching, simpler.

> Are there cases where InstructionSimplify will return a Constant that the
> constant folder won't? This code is entirely based off of a mapping to
> Constant*, so instsimplify won't help without more refactoring.
> That refactoring would be scary because while we can represent the arbitrary
> values, we'll find ourselves effectively unrolling the loop as we build up a
> larger and larger SCEV expression. I'd like to leave unrolling to the
> unrolling pass.

Well, sure, you don't want to SCEV an expression if the representation
isn't useful... that said, it seems like you only care that the
returned value is loop-invariant.

-Eli