search for: scalarevolutionexpressions

...For example, I might get away with a .h file including only #include "llvm/Analysis/AliasAnalysis.h" #include "llvm/Analysis/LoopInfo.h" #include "llvm/ADT/SmallBitVector.h" and a .cpp file including only #include "myHeader.h" #include "llvm/Analysis/ScalarEvolutionExpressions.h" #include "llvm/Analysis/ValueTracking.h" #include "llvm/Support/InstIterator.h" Is it good style to cut the list down to the bare minimum like this? Thanks, Preston -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.or...

We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal llvm::SCEVVisitor<SC, RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use of SCEVCouldNotCompute!"' failed. This happens in SCEVExpander::visitAddRecExpr where we...

David Greene wrote: > We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: > > llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal > llvm::SCEVVisitor<SC, > RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = > llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use of > SCEVCouldNotCompute!"' failed. > > This happens in SCEVExpa...

On Friday 27 February 2009 00:50, Nick Lewycky wrote: > David Greene wrote: > > We've upgraded to llvm 2.4 and we're hitting an assert in SCEV: > > > > llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:669: RetVal > > llvm::SCEVVisitor<SC, > > RetVal>::visitCouldNotCompute(llvm::SCEVCouldNotCompute*) [with SC = > > llvm::SCEVExpander, RetVal = llvm::Value*]: Assertion `0 && "Invalid use > > of SCEVCouldNotCompute!"' failed. > > > >...

Hi Geoff, Firstly, I think it will be great if you have a small reproducer of this issue (which I can make fail after re-applying D18001 to ToT). > I’ve run into what appears to be a bug in ScalarEvolution, but I’m not sure > if it is instead caused by me missing an implicit assumption between LSR and > SCEV. > > This issue is caused by the change D18001, which is an attempt to

...h sort at some > point, so I think they're all sorted. #include "llvm/Analysis/AliasAnalysis.h" #include "llvm/Analysis/AliasSetTracker.h" #include "llvm/Analysis/ValueTracking.h" #include "llvm/Analysis/ScalarEvolution.h" #include "llvm/Analysis/ScalarEvolutionExpressions.h" I removed the last part of the list, so you don't see the problem. All, except 'ValueTracking' are sorted. >>> + // Returns the weight associated with the provided value. A chain of >>> + // candidate pairs has a length given by the sum of the weights...

Hi All, I've run into what appears to be a bug in ScalarEvolution, but I'm not sure if it is instead caused by me missing an implicit assumption between LSR and SCEV. This issue is caused by the change D18001 <http://reviews.llvm.org/D18001> , which is an attempt to increase SCEV-inserted instruction re-use by picking a more canonical insertion position in the case where a new

...\include\llvm\Analysis\ProfileInfoTypes.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Analysis\ScalarEvolution.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Analysis\ScalarEvolutionExpressions.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Analysis\Trace.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Analysis\ValueNumbering.h"> > > </File...

...nIterator.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/RegionPrinter.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/ScalarEvolution.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/ScalarEvolutionExpander.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/ScalarEvolutionExpressions.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/ScalarEvolutionNormalization.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/SparsePropagation.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/Trace.h -- Installing: /usr/local/llvm-2.8/include/llvm/Analysis/ValueTrack...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

...; RelativePath="..\..\include\llvm\Analysis\ProfileInfoTypes.h"> > </File> > <File > RelativePath="..\..\include\llvm\Analysis\ScalarEvolution.h"> > </File> > <File > RelativePath="..\..\include\llvm\Analysis\ScalarEvolutionExpressions.h"> > </File> > <File > RelativePath="..\..\include\llvm\Analysis\Trace.h"> > </File> > <File > RelativePath="..\..\include\llvm\Analysis\ValueNumbering.h"> > </File> > <File > Rela...

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel

On Fri, 2011-12-02 at 17:07 +0100, Tobias Grosser wrote: > On 11/23/2011 05:52 PM, Hal Finkel wrote: > > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: > >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: > >>> > > Tobias, > >>> > > > >>> > > I've attached an updated patch. It contains a few bug fixes

On 11/23/2011 05:52 PM, Hal Finkel wrote: > On Mon, 2011-11-21 at 21:22 -0600, Hal Finkel wrote: >> > On Mon, 2011-11-21 at 11:55 -0600, Hal Finkel wrote: >>> > > Tobias, >>> > > >>> > > I've attached an updated patch. It contains a few bug fixes and many >>> > > (refactoring and coding-convention) changes inspired