search for: jne_4

...80616); // set the number of MBB to be 19880616 which is used as an ID Pred->addSuccessor(MBB); const TargetInstrInfo *TII = MF.getTarget().getInstrInfo(); DebugLoc dl; // CALLpcrel32 abort BuildMI(MBB,dl,TII->get(X86::CALLpcrel32)).addExternalSymbol("abort"); // JNE_4 error_label BuildMI(MBB,dl,TII->get(X86::JNE_4)).addExternalSymbol("error_label"); // MOV32ri %eax, 0 BuildMI(MBB,dl,TII->get(X86::MOV32ri),X86::EAX).addImm(0); // CALL32r %eax // BuildMI(MBB,dl,TII->get(X86::CALL32r)).addReg(X86::EAX); MF.insert(I,MBB); } When...

...----------------------------- The optimizer removes the i += i; operation, hardcodes the fact that there are 19 loops, and counts down instead of up. This is irrelevant to the problem, but makes the graph clearer. The loop body produces the following SelectionDAG: http://i.imgur.com/tmJBZ.png The JNE_4 near the root of the graph depends on the flag produced by the DEC64_32r, through a CopyToReg node. Other nodes that write to the flags, such as the ADD64rr nodes on the left are not linked to the DEC64_32rr node with a WAW edge. I'm assuming that this is because they are not hardcoded to outpu...

...as an ID >> >> Pred->addSuccessor(MBB); >> const TargetInstrInfo *TII = MF.getTarget().getInstrInfo(); >> DebugLoc dl; >> // CALLpcrel32 abort >> BuildMI(MBB,dl,TII->get(X86::CALLpcrel32)).addExternalSymbol("abort"); >> // JNE_4 error_label >> BuildMI(MBB,dl,TII->get(X86::JNE_4)).addExternalSymbol("error_label"); >> // MOV32ri %eax, 0 >> BuildMI(MBB,dl,TII->get(X86::MOV32ri),X86::EAX).addImm(0); >> // CALL32r %eax >> // BuildMI(MBB,dl,TII->get(X86::CALL32r)).a...

...red for it? As it stands now, the flag sounds like a binary predicate - either relax all, or don't relax all. Maybe something like "mc-early-relaxation" would be more descriptive? Thanks in advance for any insights, Eli (*) For instance in the case of X86, the MCInst emitter shrinks JNE_4 to JNE_1 counting on relaxation in the assembler to fix it if needed.

...16396, %reg16386, %EFLAGS<imp-def>; GR16:%reg16396,16386 %reg16394<def> = COPY %reg16396; GR16:%reg16394,16396 %reg16394<def> = SHL16ri %reg16394, 1, %EFLAGS<imp-def>; GR16:%reg16394 CMP16ri %reg16394, 0, %EFLAGS<imp-def>; GR16:%reg16394 JNE_4 <BB#1>, %EFLAGS<imp-use> Successors according to CFG: BB#2 BB#1 BB#2: derived from LLVM BB %bb12 Predecessors according to CFG: BB#1 %AX<def> = COPY %reg16398; GR16:%reg16398 RET # End machine code for function test5. # After Register Allocation: # Machi...

...%EFLAGS<imp-def>, %RSP<imp-use> CALL64pcrel32 <ga:@atoi>, <regmask>, %RSP<imp-use>, %RDI<imp-use,kill>, %EAX<imp-def> ADJCALLSTACKUP64 0, 0, %RSP<imp-def>, %EFLAGS<imp-def>, %RSP<imp-use> CMP32ri %EAX<kill>, 5, %EFLAGS<imp-def> JNE_4 <BB#2>, %EFLAGS<imp-use> But at the end, I get this error : fatal error: error in backend: unsupported relocation of undefined symbol 'LBB0_0' Any idea on what can the problem be ? Thx, cheers

Hi, I'm having some trouble wirting an instruction in the X86 backend. I made a new intrinsic and I wrote a custom inserter for my intrinsic in the X86 backend. Everything works fine, except for one instruction that I can't find how to write. I want to add this instruction in one of my machine basic block: mov [rdi], 0 How can I achieve that with the LLVM api? I tried several

...lag > sounds like a binary predicate - either relax all, or don't relax all. > Maybe something like "mc-early-relaxation" would be more descriptive? > > Thanks in advance for any insights, > Eli > > (*) For instance in the case of X86, the MCInst emitter shrinks JNE_4 > to JNE_1 counting on relaxation in the assembler to fix it if needed. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...d>; GR64:%vreg5 > TEST64rr %vreg6, %vreg6, %EFLAGS<imp-def>; GR64:%vreg6 > %vreg9<def> = COPY %vreg6; GR64:%vreg9,%vreg6 > %vreg10<def> = COPY %vreg4; GR64:%vreg10,%vreg4 > %vreg11<def> = COPY %vreg5; GR64:%vreg11,%vreg5 > JNE_4 <BB#2>, %EFLAGS<imp-use,kill> > JMP_4 <BB#3> > Successors according to CFG: BB#3(4) BB#2(124) > > BB#3: derived from LLVM BB %while.end > Predecessors according to CFG: BB#0 BB#2 > Successors according to CFG: BB#4 > > BB#4: derived from L...