search for: analyzebranches

I am working on a back end for an architecture whose jump via table instruction includes 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:

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 >>

  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,

> 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.

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

On 11/12/2009, at 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

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

...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 >...

Evan, et al., I've come across a small issue when using the if conversion pass in PPC to generate conditional returns. Here's a small example: ** Before if conversion ** BB#0: derived from LLVM BB %entry %R3<def> = LI 0 %CR0<def> = CMPLWI %R3, 0 BCC 68, %CR0, <BB#3> Successors according to CFG: BB#3(16) BB#1(16) BB#1: derived from LLVM BB

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

>> 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

On Tue, Oct 18, 2011 at 4:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 18, 2011, at 3:07 PM, Chandler Carruth wrote: > > On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com>wrote: > >> I think this should really live as a CodeGen pass. Is there any good >> reason to make it an IR pass? >> > > So, as it

On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: >> As for why it should be an IR pass, mostly because once the selection dag runs through the code, we can never recover all of the freedom we have at the IR level. To start with, splicing MBBs around requires known about the terminators (which we only some of the time do), and it requires re-writing them a touch to account for the

On Oct 14, 2008, at 9:16 AM, Villmow, Micah wrote: > 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,

On Oct 15, 2008, at 11:38 AMPDT, Daniel M Gessel wrote: > 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

On Tue, Oct 18, 2011 at 6:58 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote: > > As for why it should be an IR pass, mostly because once the selection dag >> runs through the code, we can never recover all of the freedom we have at >> the IR level. To start with, splicing MBBs around requires known about

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 ability to do goto/jump, only whileloop and ifs. So analyzing the

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