similar to: [LLVMdev] Iterator issue in BranchFolder::RemoveBlocksWithHash?

On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: > Hi all, > > I updated from 2.2 to the latest SVN head and I now get a debug > assert in BranchFolder::RemoveBlocksWithHash: “vector iterators > incompatible”. I’m using Visual C++ 2005. I think this is the > culprit code: > > MergePotentials.erase(CurMPIter); > if (CurMPIter==B) > break; >

On May 23, 2008, at 10:19 AM, Dale Johannesen wrote: > On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: > >> I updated from 2.2 to the latest SVN head and I now get a debug >> assert in BranchFolder::RemoveBlocksWithHash: “vector iterators >> incompatible”. I’m using Visual C++ 2005. I think this is the >> culprit code: >> >>

On May 27, 2008, at 1:40 PM, Mike Stump wrote: > On May 23, 2008, at 10:19 AM, Dale Johannesen wrote: >> On May 23, 2008, at 4:10 AM, Nicolas Capens wrote: >> I also am not a STL guru; the standard says erase >> "Invalidates all the iterators and references after the point of the >> erase" >> which is not wonderfully worded, but I take it to mean an

On May 27, 2008, at 2:01 PM, Dale Johannesen wrote: > On May 27, 2008, at 1:40 PM, Mike Stump wrote: >> >> From n2461: >> >>> 8 The insert members shall not affect the validity of iterators and >>> references to the container, and the erase members shall invalidate >>> only iterators and references to the erased elements. >> >> Pretty

It would go something like like the code below. The goal would be to turn the basic blocks which the graph looks like "...->x->y->..." where the instructions of x and y could live in the same basic block without a jump or fall through in between. bool runOnMachineFunction(MachineFunction &mf) { BitVector seen( mf.size() ); for( unsigned i = 0, e = mf.size();

According to the docs, InsertBranch should only be called if AnalyzeBranch returns success. But in targets (like ARM or Sparc) that don't implement them, the following test fails: ----------------------------------- void %__gcov_init() { entry: switch uint 0, label %cond_true.i [ uint 0, label %UnifiedReturnBlock uint 875573313, label

I think what's happening is BranchFolder::MaintainLiveIns is using a forward analysis on top of these missing kill flags, and updating the BB-live-ins/live-outs with an incorrect set of registers. Then when the stackmaps liveness analysis happens, it's not doing anything wrong, but it starts with the wrong set of live registers and will propagate those to the point of the

On Feb 1, 2011, at 1:34 PM, Andrew Trick wrote: > On Feb 1, 2011, at 1:08 PM, Andrew Clinton wrote: > >> I have a (non-entry) basic block that contains only PHI nodes and an >> unconditional branch (that does not branch to itself). Is it always >> possible to merge this block with it's successor and produce a >> semantically equivalent program? I'm

Has anyone written a pass at the MachineFunction level which combines machine basic blocks which is guaranteed to be the single predecessor to another block? Or is there a reason not to combine them? - Thanks Jeff Kunkel

Dear all, I use the clang frontend to produce the control flow graph of a C program through this command: clang -Xclang -analyze -Xclang -analyzer-checker=debug.DumpCFG test.c The produced information contains all the basic blocks identified by labels, e.g. B1, B2, etc. along with their predecessors and successors. Is there a way to get the starting address of each of these basic block? I would

On Oct 6, 2010, at 4:31 PM, Jeff Kunkel wrote: > Has anyone written a pass at the MachineFunction level which combines > machine basic blocks which is guaranteed to be the single predecessor > to another block? Or is there a reason not to combine them? I'm not sure exactly what transformation you're referring to, but BranchFolder::OptimizeBranches does a lot of things like that.

On 02/01/2011 04:47 PM, Andrew Trick wrote: > > I forgot to ask why you're doing this. If the goal is to remove a branch, that would typically be handled by BranchFolder during codegen after phis have been removed. I don't see a problem forcing the CFG to be more canonical earlier, but if the successor is in a deeper loop, then you could be eliminating a preheader and forcing

What are the rules regarding iterator stability for SmallPtrSet? I'm running into a problem where erasing an element seems to invalidate iterators that are not pointing at the erased element. Specifically, the set is in small mode, I advance an iterator to the last element in the set (not end(), but one before) and then erase the second-to-last element. I understand that the last element

> On Dec 10, 2015, at 9:39 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > ----- Original Message ----- >> From: "Quentin Colombet" <qcolombet at apple.com> >> To: "Derek Schuff" <dschuff at google.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org >> Sent: Wednesday, December

Hi! Does anyone know how it should be interpreted when one MI has multiple MachineMemOperands? (I've tried to find information but could not find any clear definition.) For example BranchFolder may do things like this (also see https://godbolt.org/z/iphFH4): # *** IR Dump Before Control Flow Optimizer ***: bb.0.entry: ... JCC_1 %bb.2, 5, implicit killed $eflags JMP_1 %bb.1 bb.1.s1:

> On Dec 10, 2015, at 10:49 AM, Derek Schuff <dschuff at google.com> wrote: > > > > On Thu, Dec 10, 2015 at 10:13 AM Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: > > I am tempted to think no, we don’t, but I don’t know the use cases. > What post-RA passes with want to run with virtual regs? > > The immediate

I've ran across an issue in BranchFolding.cpp where it is incorrectly folding a branch to the wrong fallthrough location. This is in LLVM 2.4 and seems to be in 2.5 also. The code in question is: void BranchFolder::OptimizeBlock(MachineBasicBlock *MBB) { MachineFunction::iterator FallThrough = MBB; ++FallThrough; // If this block is empty, make everyone use its fall-through, not

On Tue, 4 Dec 2007, David Greene wrote: > What are the rules regarding iterator stability for SmallPtrSet? > I'm running into a problem where erasing an element seems > to invalidate iterators that are not pointing at the erased element. Interesting question. > Specifically, the set is in small mode, I advance an iterator to the last > element in the set (not end(), but one

Hi all, I've run into a couple bugs recently that affected stackmap liveness analysis in various ways: http://llvm.org/bugs/show_bug.cgi?id=19224 - function arguments stay live unnecessarily http://llvm.org/bugs/show_bug.cgi?id=21265 - eflags can end up as a live out http://llvm.org/bugs/show_bug.cgi?id=21266 - %rip can end up as a live out The first two have nothing to do with stackmaps

Hi All, While reading LLVM source code, sometimes I am wondering when should we use auto instead of iterator/const_iterator. I want to use the patch [1] I sent before as an example. Could someone give me advice/guideline here? Also, I have another question. Sometimes the for-loop uses const_iterator, say for (SUnit::const_succ_iterator I = SU->Succs.begin(), E = SU->Succs.end();