search for: predicatesimplifi

...rience with C++. :-) Do you know where these >>> allocations are? >> >> I don't mind if people help out, so here's some information: >> > Could you try this (massively hacky) patch out to see if it fixes your > problem? > > Index: lib/Transforms/Scalar/PredicateSimplifier.cpp > =================================================================== > --- lib/Transforms/Scalar/PredicateSimplifier.cpp (revision 51554) > +++ lib/Transforms/Scalar/PredicateSimplifier.cpp (working copy) > @@ -674,6 +674,15 @@ > const_iterator begin() const { return Re...

...gt; of us have a lot of experience with C++. :-) Do you know where these >> allocations are? > > I don't mind if people help out, so here's some information: > Could you try this (massively hacky) patch out to see if it fixes your problem? -bw Index: lib/Transforms/Scalar/PredicateSimplifier.cpp =================================================================== --- lib/Transforms/Scalar/PredicateSimplifier.cpp (revision 51554) +++ lib/Transforms/Scalar/PredicateSimplifier.cpp (working copy) @@ -674,6 +674,15 @@ const_iterator begin() const { return Relations.begin(); }...

...ing created and see if the values for it aren't being initialized. If they are being initialized, then set a watch on the node to see where they get overwritten. -bw > ... > gmake[3]: Entering directory `/nfs/llvm/obj/powerpc/lib/Transforms/ > Scalar' > llvm[3]: Compiling PredicateSimplifier.cpp for Debug build > /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp: In > constructor '<unnamed>::InequalityGraph::Edge::Edge()': > /nfs/llvm/src/llvm/lib/Transforms/Scalar/PredicateSimplifier.cpp:607: > warning: format '%p' expects type 'v...

.... The reason it sometimes causes a failure may be related to whether NI is dereferenced after it's being clobbered. This is highly platform specific, as well as optimization specific. The problem exists on all platforms that I've seen so far. In short: The call to update() on line 1612 of PredicateSimplifier.cpp can result in the resizing of the node vector, which breaks dereferencing NI in the call to update() on line 1613 of PredicateSimplifier.cpp. (gdb) run Starting program: /nfs/llvm/obj/amd64/Debug/bin/opt -predsimplify - disable-output < ../powerpc/x.bc [New LWP 100066] [New Thread 0xd040...

.../llvm/llvm/include/llvm/ADT/FoldingSet.h:151: note: void llvm::FoldingSetImpl::NodeID::AddInteger(unsigned int) /home/afrisch/llvm/llvm/include/llvm/ADT/FoldingSet.h:152: note: void llvm::FoldingSetImpl::NodeID::AddInteger(uint64_t) ... Before that, I get some warnings: ... llvm[3]: Compiling PredicateSimplifier.cpp for Debug build PredicateSimplifier.cpp: In member function `bool <unnamed>::VRPSolver::below(llvm::Instruction*)': PredicateSimplifier.cpp:1417: warning: control reaches end of non-void function PredicateSimplifier.cpp: In member function `bool <unnamed>::DomTreeDFS::domin...

...endling wrote: > Let us know if you would like extra eyes on the two PPC failures. Many > of us have a lot of experience with C++. :-) Do you know where these > allocations are? I don't mind if people help out, so here's some information: FAIL: /nfs/llvm/src/llvm/test/Transforms/PredicateSimplifier/ 2006-11-04-ReplacingZeros.ll Failed with signal(SIGABRT) at line 1 while running: llvm-as < /nfs/llvm/src/llvm/test/Transforms/ PredicateSimplifier/2006-11-04-ReplacingZeros.ll | opt -predsimplify - disable-output Assertion failed: (validPredicate(R) && "Invalid predicate.&quo...

...n Vista. > Is LLVM supposed to work with this version of GCC (probably using the > -mno-cygwin option to get a Mingw-like behavior)? Honestly speaking, I never tried this. I always used "plain" mingw32 plus msys as a shell. Wiki mentions exactly this case. > llvm[3]: Compiling PredicateSimplifier.cpp for Debug build > PredicateSimplifier.cpp: In member function `bool > <unnamed>::VRPSolver::below(llvm::Instruction*)': > PredicateSimplifier.cpp:1417: warning: control reaches end of non-void > function > PredicateSimplifier.cpp: In member function `bool > <...

PredicateSimplifier is a pretty interesting pass, but it doesn't look like opt invokes it at any standard -Ox level, and so I assume that llvm-gcc also does not use this pass? If that is right, I'm curious about why this is the case -- does it simply not provide enough code speedup to compensate for the...

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

...failure may be related to whether NI is dereferenced after it's > being clobbered. This is highly platform specific, as well as > optimization specific. The problem exists on all platforms that > I've seen so far. > > In short: > > The call to update() on line 1612 of PredicateSimplifier.cpp can > result in the resizing of the node vector, which breaks dereferencing > NI in the call to update() on line 1613 of PredicateSimplifier.cpp. > > (gdb) run > Starting program: /nfs/llvm/obj/amd64/Debug/bin/opt -predsimplify - > disable-output < ../powerpc/x.bc >...

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

Hi John, John Regehr wrote: > PredicateSimplifier is a pretty interesting pass, but it doesn't look > like opt invokes it at any standard -Ox level, and so I assume that > llvm-gcc also does not use this pass? If that is right, I'm curious > about why this is the case -- does it simply not provide enough code > speedup t...

Chris do you have a sense for how the definedness of signed overflow in LLVM would play out in the context of bounds check elimination? That is, would it cause lots of failure to eliminate checks that could be seen to be unnecessary at the C level? John On Sun, 15 Feb 2009, Chris Lattner wrote: > > On Feb 15, 2009, at 10:08 PM, John Regehr wrote: > >>> Predsimplify is

...151: note: void > llvm::FoldingSetImpl::NodeID::AddInteger(unsigned int) > /home/afrisch/llvm/llvm/include/llvm/ADT/FoldingSet.h:152: note: void > llvm::FoldingSetImpl::NodeID::AddInteger(uint64_t) > ... > > Before that, I get some warnings: > > ... > llvm[3]: Compiling PredicateSimplifier.cpp for Debug build > PredicateSimplifier.cpp: In member function `bool > <unnamed>::VRPSolver::below(llvm::Instruction*)': > PredicateSimplifier.cpp:1417: warning: control reaches end of non-void > function > PredicateSimplifier.cpp: In member function `bool > <unn...

On Feb 15, 2009, at 10:08 PM, John Regehr wrote: >> Predsimplify is believed to have bugs (it results in miscompiled >> programs) and certainly isn't efficient (it was written before much >> of >> include/ADT). Finally, predsimplify is likely to go away once I or >> someone else writes a proper VRP pass. > > Whoever does this, I strongly encourage looking

...review these changes that'd be greatly appreciated. Meanwhile I'll try to get setup with patch, diff and a cvs drop. I have some other things I'd like to contribute (a new AsmWriter, and proper cross-compilation support from X86 to PPC). Thanks, Jaap Suter - http://jaapsuter.com * PredicateSimplifier.cpp, line 236, add: friend bool operator<(unsigned to, const Edge &edge) { return to < edge.To; } * PredicateSimplifier.cpp, line 677, add: friend bool operator<(const Value *value, const ScopedRange &range) { return value < range.V; } Lacking these operators, it generates so...

Hi all, I'm hitting the following assert in PredicateSimplifier.cpp:961 : assert(!CR.isSingleElement() && "Refusing to store single element."); If I ignore it the generated code appears correct so I'm not sure what this assert is supposed to be for. Am I doing something wrong on my end or is this a superfluous assert or it really...

> Predsimplify is believed to have bugs (it results in miscompiled > programs) and certainly isn't efficient (it was written before much of > include/ADT). Finally, predsimplify is likely to go away once I or > someone else writes a proper VRP pass. Whoever does this, I strongly encourage looking into using (or at least providing optional support for) the Apron library:

...review these changes that'd be greatly appreciated. Meanwhile I'll try to get setup with patch, diff and a cvs drop. I have some other things I'd like to contribute (a new AsmWriter, and proper cross-compilation support from X86 to PPC). Thanks, Jaap Suter - http://jaapsuter.com * PredicateSimplifier.cpp, line 236, add: friend bool operator<(unsigned to, const Edge &edge) { return to < edge.To; } * PredicateSimplifier.cpp, line 677, add: friend bool operator<(const Value *value, const ScopedRange &range) { return value < range.V; } Lacking these operators, it generates so...

Reid Spencer wrote: If you haven't confirmed your attendance yet, please do so by > responding to this email. I'll be there. Furthermore, I'd like to present the Design and Implementation of the PredicateSimplifier pass, or, "VRP in LLVM". Nick Lewycky