search for: isbranch

...sassembler/llvm/DisassemblerLLVMC.cpp:87 - "const bool can_branch = mc_disasm_ptr->CanBranch(inst);"), while trying to set the next breakpoint. On this case, the instruction is the "bne cr7,0x2000092c", which is a branch, but at llvm/lib/MC/MCInstrDesc.cpp:35 - "if (isBranch() || isCall() || isReturn() || isIndirectBranch())" it returns false, making lldb do not set the correct breakpoint, so the execution does not stop at next line, which should be the "step over" behavior. The variable "Flags" for the disassembled instruction does not have t...

The `isBranch` flag is already set on the branch instructions. Furthermore, we do use the `isBranch()` query in a few places in the PPC back end, so this does work. Perhaps there's something specific about the lldb usage? Is it somehow possible that the `isBranch()` query is called on the wrong instruction?...

....com] > *Sent:* quinta-feira, 30 de novembro de 2017 07:54 > *To:* Sean Fertile <sd.fertile at gmail.com> > *Cc:* Leonardo Bianconi <leonardo.bianconi at eldorado.org.br>; > llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] PPC64 Disassembler > > > > The `isBranch` flag is already set on the branch instructions. > Furthermore, we do use the `isBranch()` query in a few places in the PPC > back end, so this does work. Perhaps there's something specific about the > lldb usage? Is it somehow possible that the `isBranch()` query is called on > the...

...ilation by hoisting a divide by zero instruction out of the loop. Clearly this pass needs to be made aware that this is not safe. The current test in the MachineLICM is as follows: // Ignore stuff that we obviously can't hoist. if (TID.mayStore() || TID.isCall() || TID.isReturn() || TID.isBranch() || TID.hasUnmodeledSideEffects()) return false; Setting hasSideEffects = 1 seems to work, but I'm not sure if that's the intended use of this flag. I notice that divide / remainder instructions for other architectures are not marked in this way. Also it is also pessimistic:...

...ense to group the reg-reg and reg-imm instruction definitions separately. The main downside is that this style is not quite as concise as specifying patterns alongside the instruction definition. Repetition seems to be effectively reduced with a few simple Pat classes. Semantic information such as isBranch is still represented in the instruction definition meaning there isn't a complete split between MC-layer and codegen concerns. The Mips{64,32}r6InstrInfo.td does also factor out this information. This seems less compelling to me, but dissenting opinions are welcome! I've demonstrated both...

...ive jump) to a given offset. I've described in tablegen this instruction as follow: def DECJNZ : Instruction { let Namespace = "MyTarget"; let OutOperandList = (outs GprRegs:$R0); let InOperandList = (ins GprRegs: $R1, imm16:$dest); let AsmString = "DECJNZ $R0, $dest"; let isBranch = 1; let isTerminator = 1; let Constraints = "$R1 = $R0"; let Defs = [SR]; } I would like to create an optimization pass to make countable loops faster by using this instruction. The simplest loop that I would like to optimize is like: ////////////////////////// int i = a; do { //...

...60 [ORD=1] [ID=11] 0x16d5748: ch = EntryToken [ORD=1] [ID=0] 0x170db60: i16 = Register %reg16387 [ORD=1] [ID=1] 0x170ec00: i16 = Constant<0> [ORD=1] [ID=8] 0x170ef00: ch = BasicBlock<bb1 0x170a5d8> [ID=10] In my InstrInfo.td file I'm trying to match BRCOND as follows: let isBranch = 1 in def CondBranch : F3_1<2, 0b000101, (outs), (ins IntRegs:$L, i16imm:$R, brtarget:$dst), "; TODO: do conditional branching.", [(brcond (seteq IntRegs:$L, simm8:$R), bb:$dst)]>; I know CondBranch only handles SETEQ, but it should stil...

...ue /// for instructions whose effects are captured by: /// /// 1. Their operand list and implicit definition/use list. Register use/def /// info is explicit for instructions. /// 2. Memory accesses. Use mayLoad/mayStore. /// 3. Calling, branching, returning: use isCall/isReturn/isBranch. Now you initially reported that "TableGen will (correctly) complain about a mismatch of mayLoad and hasSideEffects", I believe this is incorrect considering the above description. -- Mehdi > > At the IR level, the definition of "mayHaveSideEffects" is more coherent...

On Tue, Oct 10, 2017 at 4:48 PM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 10/9/2017 3:10 AM, Gaël Jobin via llvm-dev wrote: > > Hi all, > > I got a silly bug when compiling our project with the latest Clang. Here's > the outputted assembly: > > tst r3, #255 > strbeq r6, [r7] > ldreq r6, [r4, r6, lsl #2] > strne r6, [r7, #4]

...9;ve described in tablegen this instruction as follow: > > def DECJNZ : Instruction { > let Namespace = "MyTarget"; > let OutOperandList = (outs GprRegs:$R0); > let InOperandList = (ins GprRegs: $R1, imm16:$dest); > let AsmString = "DECJNZ $R0, $dest"; > let isBranch = 1; > let isTerminator = 1; > let Constraints = "$R1 = $R0"; > let Defs = [SR]; > } > > I would like to create an optimization pass to make countable loops faster by > using this instruction. > > The simplest loop that I would like to optimize is like: > &gt...

...compares. I then looked at ARM, where it uses the HardwareLoops pass first, and then a combine that occurs in the ARM ISel stage. It replaces branch instructions with special 'WLS' and 'LE' nodes that are custom selected into t2WhileLoopStart and t2LoopEnd pseudo instructions with isBranch and isTerminator set. These pseudo instructions are finalized in a later MachineFunctionPass. I had originally intended to use the HardwareLoops pass to do most of the initial transformation and bookkeeping, allowing me to utilize the generated intrinsics in my own pass to further transform and cu...

TargetInstrDesc::isBranch() will return true if a branch occurs, and it may be accessed though MachineInstr::getDesc(). Jeff Kunkel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100903/b9593885/attachment.html>

Hello Per, > The CMPrr instruction is moved down to after the PHI node. My guess is that > the 'dead' in CFR<imp-def,dead> is to blame, but I can't see what I'm doing > differently from MSP430/sparc that makes this not work. Any help GREATLY > appreciated! It seems like no use of CFR after CMP, indeed. How condbranches on your platform look like (patterns, etc.)

...should certainly be defined by the time the function does return). Since you've marked *any* JMP as a return, they all seem to get the extra R0, even if the instructions that actually define it hasn't been executed yet. I'd make isReturn only apply to the RET (and probably add an "isBranch" to all of them for good measure). Tim.

...D::CMP", SDTIntBinOp, [SDNPOutFlag]>; let Defs = [CFR] in { def CMPrr : InstCS<(outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c), "cmp $c, $dst", [(set IntRegs:$dst, (cmpcc IntRegs:$b, IntRegs:$c)), (implicit CFR)]>; } let Uses = [CFR], isBranch = 1, isTerminator = 1 in def SKIPCOND : InstCS<(outs), (ins CCOp:$cc), "s$cc", [(skipcc imm:$cc)]>; On Wed, Dec 15, 2010 at 10:02 AM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > Hello Per, > > > T...

...his instruction as follow: >> >> def DECJNZ : Instruction { >> let Namespace = "MyTarget"; >> let OutOperandList = (outs GprRegs:$R0); >> let InOperandList = (ins GprRegs: $R1, imm16:$dest); >> let AsmString = "DECJNZ $R0, $dest"; >> let isBranch = 1; >> let isTerminator = 1; >> let Constraints = "$R1 = $R0"; >> let Defs = [SR]; >> } >> >> I would like to create an optimization pass to make countable loops faster by >> using this instruction. >> >> The simplest loop that I woul...

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

Hello! I'm working on a new back-end and have hit a bit of a snag. I'm working on getting selectcc working and have followed the MSP430 model of emitting a custom CMP and SELECT_CC node and matching that with a pseudo-instruction that has useCustomEmitter=1. However, my output ends up very wrong, despite the Machine code being initially correct: # Machine code for function func: Function

...Requires<[Is32Bit]>; + def EH_SJLJ_LONGJMP32rr : Pseudo<(outs), (ins MEMrr:$buf), + "#EH_SJLJ_LONGJMP32", + [(SPsjlj_longjmp ADDRrr:$buf)]>, + Requires<[Is32Bit]>; + } + + let isBranch = 1, isTerminator = 1 in { + def EH_SjLj_Setup : Pseudo<(outs), (ins brtarget:$ptr), + "#EH_SjLj_Setup\t$ptr", []>, + Requires<[Is32Bit]>; + } + // Section B.1 - Load Integer Instructions, p. 90 let DecoderMethod = "De...

I have defined the intrinsic as * def int_loop: Intrinsic<[],[llvm_i8_ty, llvm_empty_ty],[]>;* and also got the Codegen backend support in Instructioninfo.td file. Then created a .ll file to test it. The .ll file is like this *declare void @llvm.loop(i8, label)define void @fn() nounwind readnone {entry: ..... ..... call void @llvm.loop(i8 10, label %entry) ret void}* But