similar to: [LLVMdev] Selecting BRCOND instead of BRCC

Hi! I'm trying to build a backend outside the LLVM source tree. My directory structure is as follows: llvm -- the root of the LLVM source tree llvm/lib/Target -- where the standard backends are stored (Sparc, etc). my_dir/my_backend -- where I store the backend I'm writing. I've been fiddeling with the variables documented in the llvm/Makefile.common (LEVEL, LLVM_SRC_ROOT,

Hi Eli, Thanks again for your reply. I am unsure about implementing the getCrossCopyRegClass for my target. My target does not support or allow moves to and from the SR. The SR exists because it has implicit involvement in some instructions, but it is opaque to the assembler and to the user as a register. I mean, there are no instructions to directly move or read it, or even access it directly.

I am implementing a new backend and am pretty sure I don't quite understand "the way" one is supposed to implement conditional branches. My target CPU natively supports a conditional branch instruction 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

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

I am wondering how to express physical register dependencies between instructions, typically in the case for conditionnal branch, where an instruction which sets the condition codes is followed by a conditionnal branch. Assuming CCFLAGS is defined in my registerInfo.td, and that I am using llvm-2.5 release, it seems several items need to be set in the .td file : 1 - SDNPOptInFlag / SDNPOptOutFlag

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

Hi, I find it's quite strange how condition dependent instructions are processed in PeepholeOptimizer::runOnMachineFunction: 01577 if ((isUncoalescableCopy(*MI) && 01578 optimizeUncoalescableCopy(MI, LocalMIs)) || 01579 (MI->isCompare() && optimizeCmpInstr(MI, &MBB)) || 01580 (MI->isSelect() && optimizeSelect(MI,

Hi Quentin, Yes, the code allows to process connected instructions. Although it should be taken into account that the instruction next to the current processed instruction must never be erased because this invalidates iterator. I've been fixing a bug in AArch64InstrInfo::optimizeCompareInstr: instructions are converted into S form but it's not checked that they produce the same flags as

Hi, I am having some issues with how some of the instructions are being legalized. So this is my intial basic block. The area of concern is the last three instructions. I will pick and choose debug output to keep this small. SelectionDAG has 36 nodes: t0: ch = EntryToken t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507 t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17

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,

But isn't kinda silly that we transform to xor and then we transform it back. What is the advantage in doing so? Also, since we do that method, I now have to introduce setcc patterns for i1 values, instead of being able to just use logical pattern operators like not. -Dilan On Fri, Jul 21, 2017 at 11:00 AM Dilan Manatunga <manatunga at gmail.com> wrote: > For some reason I

Hi debuginfo-cabal, tl;dr: Let's please consider using a new implementation of LiveDebugValues that produces richer information, might be slightly faster, but mostly will support the instruction referencing and value tracking paradigm from my RFC [0] rather than the location tracking that LiveDebugValues does today. In that RFC, the main motivator is to treat variable locations a bit more

Hi there, I am currently trying to create an LLVM Backend for a RISC architecture and running into problems with setCC and brcond. First a few explanations: The architecture doesn't have a dedicated flag register, but seven 1-bit-wide so called "condition registers", c0-c6, which can be set by e.g. a compare instruction: > cmp ne, c0, r1, 123 It also supports conditional