[llvm-commits] [PATCH/RFC] Loop Data Software Prefetching

[Hal Finkel]

----- Original Message -----
> From: "Andrew Trick" <atrick at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Evan Cheng" <evan.cheng at apple.com>, "l >> Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Friday, February 1, 2013 12:45:51 AM
> Subject: Re: [llvm-commits] [PATCH/RFC] Loop Data Software Prefetching
> 
> 
> 
> 
> On Jan 29, 2013, at 12:39 PM, Hal Finkel < hfinkel at anl.gov > wrote:
> 
> 
> 2. Applying this patch causes three regression test failures:
> LLVM :: CodeGen/X86/lsr-negative-stride.ll
> LLVM :: Transforms/LoopStrengthReduce/X86/2011-12-04-loserreg.ll
> LLVM :: Transforms/LoopStrengthReduce/X86/2012-01-13-phielim.ll
> 
> these failures are triggered just by the fact that the pass is
> scheduled prior to LSR running, even though it does not change
> anything. Does anyone know how this might happen?
> 
> I'm not sure, but I'm curious. Can you print the IR input to LSR in
> each case and also debug-pass=Executions? Prefetching must have
> either invalidated an analysis or changed the loop pass manager.

Here's the funny part: If I comment out:
AU.addPreserved<ScalarEvolution>();
in the LoopDataPrefetch pass, then all of the regression tests pass as expected.

And, to be clear, the bug is triggered by the LoopDataPrefetch pass doing nothing, meaning:
bool LoopDataPrefetch::runOnLoop(Loop *L, LPPassManager &LPM) {
  return false;
}

So, for some reason, preserving ScalarEvolution is problematic.

 -Hal

> 
> 
> Meanwhile, I'm fixing these tests to use opt -loop-reduce directly so
> it doesn't happen again.
> 
> 
> -Andy