similar to: [LLVMdev] A basicblock iterator bug in llvm

On 27 Sep., 05:45, hc2... at columbia.edu wrote: > Dear developers: >      When I am doing basicblock pass, I meet a bug: there is an   > iterator "I" in a basicblock, and it is not pointing to the first   > instruction in this basicblock. However, "I--;" will fail by an   > assertion. Hi hc! are you on SVN trunk? Cheers, Gabor > > The basic block

AAAH! I see you are still at 2.5. Then this patch (the fix) is relevant for you: <http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/ ilist.h?r1=66061&r2=68785&diff_format=h> Cheers, Gabor On 27 Sep., 05:45, hc2... at columbia.edu wrote: > Dear developers: >      When I am doing basicblock pass, I meet a bug: there is an   > iterator "I" in

Quoting Gabor Greif <ggreif at gmail.com>: Hi Gabor, I can not open the link, can you send again? > AAAH! > > I see you are still at 2.5. Then this patch (the fix) > is relevant for you: > > <http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/ > ilist.h?r1=66061&r2=68785&diff_format=h> > > Cheers, > > Gabor > > >

I get the following error when I try to run arm lli on QEMU: lli: llvm-arm/src/llvm/include/llvm/ADT/ilist.h:197: typename bidirectional_iterator<NodeTy, int>::reference llvm::ilist_iterator<NodeTy>::operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing end()!"' failed. 0 lli 0x006abbfc Stack dump: 0.

Hello, Thank you for your answer. If I want to use then I have error: ‘NodeTy* llvm::ilist_half_node<NodeTy>::getPrev() [with NodeTy = llvm::Instruction]’ is protected error: ‘llvm::ilist_half_node<llvm::Instruction>’ is not an accessible base of ‘llvm::Instruction’ Do you know any other method to access the previous instruction of a terminator instruction? PS: back() is not an

Dear staff, I downloaded an llvm version from the svn trunk at June 12, because the released 2.5 version can not support "gcc -g -Ox", and x=1,2,3. I use the version in svn to compile an httpd.bc file succefully with dbgstoppoint() functions. However, when I use llc to compile the bc file to .s file (llc -f -o httpd.s httpd.bc), I met this error (the httpd.bc file will be

Hello John, I was following your procedures and I isolated the problem. The problem are represented by the basic blocks with only one element. for (Function::iterator II = F.begin(), EE = F.end(); II != EE; ++II, ++ii) { BasicBlock* BB=II; if (BB->getTerminator()) { Instruction* current = BB->getTerminator(); Instruction* previous;

hannibal hannibal wrote: > I get the following error when I try to run arm lli on QEMU: > > lli: llvm-arm/src/llvm/include/llvm/ADT/ilist.h:197: typename bidirectional_iterator<NodeTy, int>::reference llvm::ilist_iterator<NodeTy>::operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing end()!"'

Hi, Can anyone tell me how to erase an instruction, (specially a load/store instruction) ? If I use Instr->eraseFromParent(), I get following error. Note the instruction does not have any use. opt: /home/chayan/llvm/llvm-2.6/include/llvm/ADT/ilist.h:218: llvm::ilist_iterator<NodeTy>& llvm::ilist_iterator<NodeTy>::operator++() [with NodeTy = llvm::Instruction]: Assertion

getPrevNode<http://llvm.org/docs/doxygen/html/classllvm_1_1ilist__node.html#a77b897207ef0a1ae95c404695aed9a4b>() Get the previous node, or 0 for the list head. I don't see any method like hasPrevNode. It can be a weird problem because "current->getPrevNode()" is indicating to "current" itself (the problem appears for the BB with only one element)? On Thu, Dec

I may be mistaken as I just took a quick look, but in ilist_node the function "getPrevNode()" actually calls a method on the previous node: NodeTy *getPrevNode() { NodeTy *Prev = this->getPrev(); // Check for sentinel. if (!Prev->getNext()) return 0; return Prev; } http://llvm.org/docs/doxygen/html/ilist__node_8h_source.html#l00058 Try checking if

I solved by checking if(BB->size()>1) Thank you all for the help ! Now debugging the next segfault. On Thu, Dec 20, 2012 at 12:59 PM, Alexandru Ionut Diaconescu < alexandruionutdiaconescu at gmail.com> wrote: > getPrevNode<http://llvm.org/docs/doxygen/html/classllvm_1_1ilist__node.html#a77b897207ef0a1ae95c404695aed9a4b>() > Get the previous node, or 0 for the list

The warning is: R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(58) : warning C4099: 'llvm::ilist_sentinel_traits<llvm::SparseBitVectorElement<ElementSize>>' : type name first seen using 'struct' now seen using 'class' R:\SDKs\llvm\trunk\include\llvm/ADT/SparseBitVector.h(275) : see reference to class template instantiation

I think the implicit iterator conversions are much less important now that we have range based for loops, but I still like having them. On Tue, Oct 20, 2015 at 11:13 AM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 2015-Oct-07, at 17:57, Duncan P. N. Exon Smith <dexonsmith at apple.com> > wrote: > > > > I've been

Dear all, The below has been tested quite thoroughly by now, including performance-testing by the way of using a modified compiler that triggers the below while compiling at least an old part of LLVM ["Function.cpp"] and sorting a symbol table with >7000 global variables. Unfortunately, the optimization I have been working on for which I _thought_ I needed the ability to sort a

"Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at lists.llvm.org> writes: >> On 2015-Oct-20, at 11:23, Reid Kleckner <rnk at google.com> wrote: >> >> I think the implicit iterator conversions are much less important >> now that we have range based for loops, but I still like having >> them. > > IMO, if a developer has an ilist iterator

Hi, it looks like the IntervalPartition does not work as expected when constructed from another interval partition. Say, I have built an interval partition from function, and the first interval has two basic blocks. When I create second order partition and print all intervals, the second basic block of the function is not seen anywhere. Here's what's going on in IntervalIterator.h:

I haven't verified what Matt described is what actually happens, but assuming it is - that is a known issue in the x86 cost model. Vectorizing interleaved memory accesses on x86 was, until recently, disabled by default. It's been enabled since r284779, but the cost model is very conservative, and basically assumes we're going to scalarize interleaved ops. I believe Farhana is working

Hi Michael- Since you bring up libquantum performance can you let me know what the IR will look like for this small code snippet (libquantum-like) with –enable-cond-stores-vec ? I ask because I don’t see vectorization kicking in unless -force-vector-width=<> is specified. Let me know if I am missing something. -Thx struct nodeTy { unsigned int c1; unsigned int c2; unsigned

Hi Dibyendu, Are you using a recent compiler? What architecture are you targeting? The target will determine whether the vectorizer thinks vectorization is profitable without having to manually force the vector width. For example, top-of-trunk vectorizes your snippet with "clang -O2 -mllvm -enable-cond-stores-vec" and "--target=aarch64-unknown-linux-gnu". However, with