search for: splitcriticaledge

On May 2, 2011, at 3:51 PM, Akira Hatanaka wrote: > - vreg81's VarInfo: > Alive in blocks: 5, 6, 7, 8, 10, 12, 13, 19, > Killed by: > #0: J <BB#17> > > > As you can see, VarInfo vreg81 is killed by the unconditional jump instruction of BB#20 when it should be killed by the newly created conditional branch in BB#14 (BEQ). Is this a bug in

Does updateTerminator() need to be rewritten in order to implement the changes you suggested (call LV->replaceKillInstruction)? Or can it be taken care of just by adding code to the files in Target/Mips? Also, is the generated code still correct if -disable-phi-elim-edge-splitting is added to the command line options? On Mon, May 2, 2011 at 5:00 PM, Jakob Stoklund Olesen <stoklund at

...have a landingpad instruction as its first non-PHI > instruction. > 3. The landingpad instruction must be the first non-PHI instruction in the > landing pad block. > 4. Like indirect branches, splitting the critical edge to a landing pad block > requires considerable care, and SplitCriticalEdge will refuse to do it. > 5. All landingpad instructions in a function must have the same personality > function. Could we add: - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed. - The landingpad instruction must only appear at the...

...nstruction as its first non-PHI >> instruction. >> 3. The landingpad instruction must be the first non-PHI instruction in the >> landing pad block. >> 4. Like indirect branches, splitting the critical edge to a landing pad block >> requires considerable care, and SplitCriticalEdge will refuse to do it. >> 5. All landingpad instructions in a function must have the same personality >> function. > > Could we add: > > - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed. > > - The landingpa...

Is LiveVariables updated correctly when TII->RemoveBranch and TII->InsertBranch are called in the following piece of code? - MachineBasicBlock::updateTerminator() line 307 of MachineBasicBlock.cpp: if (FBB) { // The block has a non-fallthrough conditional branch. If one of its // successors is its layout successor, rewrite it to a fallthrough // conditional branch.

...: > > - All unwind edges go to a block with a landingpad instruction. > - All non-unwind edges go to a block without a landingpad instruction. > > That then implies that unwind edges can't be split and landingpad instructions can't be moved. > >>> Why won't SplitCriticalEdge work for landing pads? Does it require more than splitting the landing pad after the landingpad instruction, and duplicating the top half? Alternatively, could we get a SplitLandingPad function? >> >> Splitting a critical edge, especially in this case, isn't necessary for correctne...

...d to make it completely clear that: - All unwind edges go to a block with a landingpad instruction. - All non-unwind edges go to a block without a landingpad instruction. That then implies that unwind edges can't be split and landingpad instructions can't be moved. >> Why won't SplitCriticalEdge work for landing pads? Does it require more than splitting the landing pad after the landingpad instruction, and duplicating the top half? Alternatively, could we get a SplitLandingPad function? > > Splitting a critical edge, especially in this case, isn't necessary for correctness. It...

Hi I run into an issue as part of splitting a critical edge during LICM. When a new basic block is created and needs to be added into the dominator tree, the block is already in the dominator tree. I print the dominator tree and I see it is added into the tree as child of node it is supposed to dominate. How do I debug to find out why/when its getting added into the tree. ? Tips/suggestions on

...;. Is special magic required to duplicate a landingpad instruction? >> > There shouldn't be any special magic involved. As you pointed out, we'd have to duplicate the landingpad instruction into each of the critical edge blocks. That sounds good to me. It's not necessary that SplitCriticalEdge can do it, I just want to be able to duplicate a landing pad without knowing the details of any particular personality function. >>> In general, the use of a value in the catch blocks will access that value via memory. >> >> Because the register allocator will spill, or becau...

...nstruction as its first non-PHI >> instruction. >> 3. The landingpad instruction must be the first non-PHI instruction in the >> landing pad block. >> 4. Like indirect branches, splitting the critical edge to a landing pad block >> requires considerable care, and SplitCriticalEdge will refuse to do it. >> 5. All landingpad instructions in a function must have the same personality >> function. > > Could we add: > > - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed. How do we lower SjLj exce...

...neBasicBlock at a specific instruction in the MBB, let us say, into MBB1 and MBB2. This instruction should go into MBB2. Also MBB1 should have an unconditional branch to MBB2 as the terminator. (quite similar to splitBasicBlock in BasicBlock.cpp) Meanwhile, I am trying to come up with a variant of SplitCriticalEdge to do this but if someone can provide the code to split a MBB, it will be of great help. Jeroen Dobbelaere-2 wrote: > > Using 'NEW_BB->setIsLandingPad(true);' seems to resolve everything. > > Greetings, > > Jeroen Dobbelaere > [...] > > > ____________...

...ng will invalidate the metadata. I don't think any change is necessary when clang emits a loop with an unconditional backedge, but someone will want to verify with some test cases. If a change is needed it should also be easy. With that design change we can remove any current workarounds from SplitCriticalEdge and simply preserve loop metadata, which remains valid by definition. -Andy

...xit block should > // have only one predecessor. > SplitEdge(L->getLoopLatch(), Exit, this); Would it make sense to move the ProfileInfo updating code into SplitEdge? That way all users of SplitEdge would automatically do the right thing. Actually, SplitEdge just delegates to either SplitCriticalEdge or SplitBlock, so those two should do the work. In TailRecursionElimination.cpp, there's logic which uses a "10-fold increase" heuristic. It would be nice if that code were factored out into a utility routine so that the profiling heuristics are more centralized. > - boo...

Hi all, this (altough a big patch) is actually pretty straight forward: It (tries) to preserve ProfileInfo in all -std-compile-opts passes and all X86-Backend passes. There is still some passes that have corner cases where the ProfileInfo is not correct after the pass. Some passes are still missing... How shall I proceed with this? Andi -------------- next part -------------- A non-text

...rst non-PHI >>> instruction. >>> 3. The landingpad instruction must be the first non-PHI instruction in the >>> landing pad block. >>> 4. Like indirect branches, splitting the critical edge to a landing pad block >>> requires considerable care, and SplitCriticalEdge will refuse to do it. >>> 5. All landingpad instructions in a function must have the same personality >>> function. >> >> Could we add: >> >> - A landing pad block is not the destination of any other kind of terminator. Only unwind edges are allowed. &g...

...description states that llvm.loop metadata is attached to terminator of a loop latch block, and accordingly Loop::getLoopID() searches for it in all loop latches (and only successfully finds it if all latches reference the same metadata) However, transforms which modify the CFG, for example using SplitCriticalEdge(), generally don't make any attempt to preserve this property. Some transforms dealing specifically with loops use getLoopID and setLoopID to preserve and reset the metadata after transformations, but function transforms such as GVN and Jump Threading can modify control flow without any attempt...

...landing pad block must have a landingpad instruction as its first non-PHI instruction. 3. The landingpad instruction must be the first non-PHI instruction in the landing pad block. 4. Like indirect branches, splitting the critical edge to a landing pad block requires considerable care, and SplitCriticalEdge will refuse to do it. 5. All landingpad instructions in a function must have the same personality function. // Semantics: The landingpad instruction defines the values which are set by the personality function upon reentry to the function, and therefore the "result type" of the landi...

...ove on. > While it's true that there are things that prevent a straightforward library division, I don't think that they will pose such a big problem. I have a brief list of things that have to be done before I can move the Machine IR stuff from CodeGen to some other library: - Move the SplitCriticalEdge method from MachineBasicBlock ( http://reviews.llvm.org/D10064). - Move the UnpackMachineBundles and FinalizeMachineBundles passes from MachineInstrBundle.cpp. (http://reviews.llvm.org/D10070 + 1 upcoming patch). - Refactor SlotIndexes.h: keep the SlotIndexes pass and move the rest to SlotIndex.h....

...gt; While it's true that there are things that prevent a straightforward library division, I don't think that they will pose such a big problem. > I have a brief list of things that have to be done before I can move the Machine IR stuff from CodeGen to some other library: > - Move the SplitCriticalEdge method from MachineBasicBlock (http://reviews.llvm.org/D10064). > - Move the UnpackMachineBundles and FinalizeMachineBundles passes from MachineInstrBundle.cpp. (http://reviews.llvm.org/D10070 + 1 upcoming patch). > - Refactor SlotIndexes.h: keep the SlotIndexes pass and move the rest to Slot...

Hi, I'm writing a ModulePass that needs critical edges split up. I have the statement AU.addRequiredID(BreakCriticalEdgesID); in my getAnalysisUsage() but the pass never gets executed. I guess I have to request pass execution for each function, but I can't get behind how to do that, since there is no analysis group for that kind of transformation. Thanks, Andi