search for: brcc

Hi everyone, I have the following code (as part of a larger function): %0 = icmp eq i16 %a, 0 ; <i1> [#uses=1] br i1 %0, label %bb1, label %bb I would like to match this with a BRCOND, but all I get is an error message when compiling the above code that say: LLVM ERROR: Cannot yet select: 0x170f200: ch = br_cc 0x170f000, 0x170ed00, 0x170dc60, 0x170ec00, 0x170ef00 [ID=19]

...t Branch and Select instructions that have a glue input, and another pair that have a GR register as input. Both map to the same machine instructions through Pattern matching in TargetInstrInfo.td. This is what I mean, for the case of the Conditional Branch instruction : let Uses = [SR] in { def BRCC : T2ccbr< "br", "br"> ; } def : Pat<(CPU74brcc_g bb:$a, imm:$cc), (BRCC jmptarget:$a, imm:$cc, 0)>; def : Pat<(CPU74brcc_i bb:$a, imm:$cc, GR16:$ins), (BRCC jmptarget:$a, imm:$cc, GR16:$ins)>; Then, in MyTargetISelDAGToDAG I create ‘CPU74brcc_g' instru...

...that accepts a condition to test (equal, less than, etc.), two operands (two registers, or one register and one immediate), and finally a target PC to branch to if the comparison succeeds. Great -- that all seems to mesh directly with the ISD::BR_CC opcode. However... I can't seem to use 'brcc' or 'br_cc' in the .td file.  Neither is recognized as a valid keyword.  I can use 'brcond', but given the capabilities of the CPU I'm targeting, it seems better to implement BR_CC directly and do setOperationAction(ISD::BRCOND, MVT::Other, Expand) to get BRCOND nodes expand...

Hi Eli, Thank you very much for your response. In fact, I had already tried the X86 approach before, i.e explicitly using the status register. This is the approach that appeals more to me. I left it parked because it also produced some problems (but I left it commented out). So I have now re-lived the code, and it works fine in most cases, but there’s a particular case that causes LLVM to stop

...CCFLAGS As a new comer to LLVM, I am missing the druid's lore to pick up the mixture of right items to have it work. I am asking the question because in our case, I observe that the pre-RA-scheduling pass moves an instruction which clobbers CCFLAGS in between my 2 instructions (set ccflags / brcc). I found on bugzilla that only the burr scheduler has been taught about physical register dependencies, so I made sure this is the one I am using. I am currently using #1 + #2 + #3, and have not yet used option #4, but I can see this is the one being used for the X86. Is this the one I should be...

> > > That's not it at all. These model instructions reading / writing > MVT::Flag a value. That just mean from the scheduler's point of view > the node that produces a MVT::Flag and the user have to be scheduled > together. Wow. That's just super confusing. So SDNPInFlag/SNDPOutFlag is used only for scheduling? I think you're misunderstanding ISD::SETCC.

Hello, I'm working on an LLVM backend for an experimental microprocessor. Work is going on nicely, and I've until now found the answer to all my questions directly in the LLVM source code, or in the documentation. However, I'm having problems with the AsmBackend class and the handling of fixups. The processor I'm working with has a single conditional branch instruction, JCC,

...cations that a value may be in, we can handle the following problem, that the current implementation cannot: entry: $rax = somedef DBG_VALUE $rax SPILL_TO_STACK %somestackslot, $rax loop: [... some code...] $rax = RESTORE_FROM_STACK %somestackslot do_things_with_rax brcc loop exit: ret Here, there's a variable spilt to the stack, that's temporarily restored in the loop. At the end of the "loop" block, the value has two locations: $rax and the stack slot. The current LiveDebugValues always follows the restore from the stack: it decides the v...