search for: analyzebranch

...ludes the range check. If the index is out of range, the jump table instruction just falls through. I implemented a pass to remove the range check generated before the jump table instruction because it is superfluous. This causes as assertion in MachineBlockPlacement.cpp: assert((!TII->analyzeBranch(*PrevBB, TBB, FBB, Cond) || !PrevBB->canFallThrough()) && "Unexpected block with un-analyzable fallthrough!"); The method MachineBasicBlock::getFallThrough() uses TII->analyzeBranch(). Using analyze branch there doesn't appear to be anyway t...

Hello Anton. Thanks for the comment. > Precisely this is the situation! There're two consecutive branches (br1cond >> and br2uncond). Inside of AnalyzeBranch, there's an opcode swap of br2uncond >> (ex. j_foward to j_backward). There I do BuildMI (newOpcode) and followed by >> br2uncond->eraseFromParent(). This results in br1cond loosing it's >> label/offset. How could I resolve this? >Your code is broken. AnalyzeBranch s...

  Hi Aries. Thanks very much! Precisely this is the situation! There're two consecutive branches (br1cond and br2uncond). Inside of AnalyzeBranch, there's an opcode swap of br2uncond (ex. j_foward to j_backward). There I do BuildMI (newOpcode) and followed by br2uncond->eraseFromParent(). This results in br1cond loosing it's label/offset. How could I resolve this? Best regards, Girish. May be you have branched to a BB which has...

> Precisely this is the situation! There're two consecutive branches (br1cond > and br2uncond). Inside of AnalyzeBranch, there's an opcode swap of br2uncond > (ex. j_foward to j_backward). There I do BuildMI (newOpcode) and followed by > br2uncond->eraseFromParent(). This results in br1cond loosing it's > label/offset. How could I resolve this? Your code is broken. AnalyzeBranch should not modify...

I was hoping to get feedback on this proposal formatted as a patch. I'd like to teach AnalyzeBranch to handle conditional returns on PPC, but the currently documented API for AnalyzeBranch doesn't support it. I propose the following enhancement to the API so that I can teach AnalyzeBranch about conditional return instructions. ---------- Forwarded message ---------- From: Kyle Butt <kyle+...

...t 10:43 AM, Anton Korobeynikov wrote: > Hi, Chris > >> That is target independent code, so you should not put sparc specific changes there. It sounds like one of the sparc-specific target hooks is wrong. > Since sparc does not provide any hooks for operation of branches (e.g. > AnalyzeBranch and friends) it might be possible that generic codegen > code is broken in absence of these hooks. Hi Anton, I've had a little time to look into this now, and I think there's actually two separate problems here. By way of example, what's happening is that the following pair of M...

On Feb 8, 2010, at 12:37 AM, Nathan Keynes wrote: > Firstly, the BNE/BA pair should be reduced to a BE (I assume this is > the responsibility of AnalyzeBranch and friends that you mention). Right. Implementing AnalyzeBranch will allow a bunch of block layout and branch optimizations to happen. > However I still wouldn't have expected that to result in the label > being omitted (assuming multiple branches are legal in an MBB). It > a...

...e llvm bugzilla. > > We sometime lose edges during IfConversion of diamonds and it’s not > obvious how to reproduce on an upstream target. The documentation for > HasFallThrough says *may* fallthrough which I interpret as “this will be > true whenever we aren’t sure” but IfConverter::AnalyzeBranches() contains > the code: > > BBI.HasFallThrough = BBI.IsBrAnalyzable && BBI.FalseBB == nullptr; > BBI.HasFallThrough really means "Has Analyzable fallthrough." So this line is correct. > > So HasFallThrough is false whenever IsBrAnalyzable is false. That is &g...

...at IfConversion.cpp, I see this function: /// RemoveExtraEdges - Remove true / false edges if either / both are no longer /// successors. void IfConverter::RemoveExtraEdges(BBInfo &BBI) { MachineBasicBlock *TBB = NULL, *FBB = NULL; SmallVector<MachineOperand, 4> Cond; if (!TII->AnalyzeBranch(*BBI.BB, TBB, FBB, Cond)) BBI.BB->CorrectExtraCFGEdges(TBB, FBB, !Cond.empty()); } and I think that this function is supposed to clean up the successors of BB#1 after merging. The problem is that the PPC implementation of AnalyzeBranch does not understand returns (conditional or otherwise)....

Hi, Chris > That is target independent code, so you should not put sparc specific changes there.  It sounds like one of the sparc-specific target hooks is wrong. Since sparc does not provide any hooks for operation of branches (e.g. AnalyzeBranch and friends) it might be possible that generic codegen code is broken in absence of these hooks. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

>> br2uncond->eraseFromParent(). This results in br1cond loosing it's >> label/offset. How could I resolve this? > Your code is broken. AnalyzeBranch should not modify anything. > > I was taking a clue from Mips/MipsInstrInfo.cpp: AnalyzeBranch :( > Could you please suggest appropriate alternative place for such a > modification? Ah sorry, my memory served me wrong. You can modify the stuff there, but very careful :) It's hard to...

...efit of doing this analysis in the CodeGen layer outweighs the cost and I was trying to clarify what the costs I perceive are. Some basic blocks are glued together and must be placed next to each other. > That situation can be recognized by "MBB->canFallThrough() && > TII->AnalyzeBranch(MBB..)". > > Treat glued-together blocks as super-blocks, and everything should be as > breezy as IR. > But that's just the thing -- a primary goal of this pass would be to *change* the fall-through pattern. Currently, that can be done very easily, although to a limited extent...

...ng this analysis in the CodeGen layer outweighs the cost and I was trying to clarify what the costs I perceive are. I think it's mostly about understanding how MBBs work. Ignoring calls and returns, most machines have three kinds of branches: 1. Unconditional 2. Conditional 3. Indirect. The AnalyzeBranch() function understands the first two kinds, so if that function returns false (as in it's false that it didn't succeed) you can move the successors around, and you know that placing a successor immediately after the block and calling updateTerminator() will give you a fall-through. If Anal...

...nting out > before blocks 3 & 5. Renumber blocks just seems to reorder the > values based on their pre-set block number, but when the CFG is > modified these number should modified also to follow the new > ordering, which is not occurring. Did you implement TargetInstrInfo::AnalyzeBranch for your target? Check out the large comment above it in TargetInstrInfo.h -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081014/79a665e2/attachment.html>

...onal > branch. > > I'm sure this depends somewhat on my target, but can there be an > arbitrary number of conditional branches before that last branch? How > about before a return? Right now, the interface assumes that a block ending with a branch has at most two successors (see AnalyzeBranch for example). There are also switch tables, which can handle some cases of what you want. > Before I dive in and generalize my analysis (probably only a minor > pain), is there any way I can get LLVM to generate BBs that are > constrained to use only one terminator instruction? Not now...

...mostly about understanding how MBBs work. > Indeed, that seems to be the case. =D Thanks for explaining things below, it helped me a lot. > Ignoring calls and returns, most machines have three kinds of branches: > > 1. Unconditional > 2. Conditional > 3. Indirect. > > The AnalyzeBranch() function understands the first two kinds, so if that > function returns false (as in it's false that it didn't succeed) you can > move the successors around, and you know that placing a successor > immediately after the block and calling updateTerminator() will give you a > fa...

Chris, I took a look at AnalyzeBranch and I don't see how it can solve my problem. The issue itself isn't with branching, as I can handle branches fairly well in my custom pass(see the before and after dot files attached). I can take a bunch of branches and construct high level control flow for my backend since I have no abilit...

I'm analyzing the basic blocks of MachineInstructions that LLVM generates for my TargetMachine to try to reconstruct high-level flow control. I misunderstood the isTerminator property of an instruction to mean that it had to be at the end of a basic block, but now I've seen blocks that end with a conditional branch followed by an unconditional branch. I'm sure this depends

Hi, there! There are situations where a machine basic block has to be split into two machine basic blocks, e.g., to place a constant pool entry or to fix a conditional branch so that its target is within its range (https://reviews.llvm.org/D38918). However, it doesn't appear to be straightforward how the control flow graph should be updated when a machine basic block is split,

But, the branch folding pass, or whatever passes are supposed to reorder the blocks based on the CFG, are not doing so in this case. Otherwise there is no way that blocks 2 and 4 should be printing out before blocks 3 & 5. Renumber blocks just seems to reorder the values based on their pre-set block number, but when the CFG is modified these number should modified also to follow the new