similar to: [LLVMdev] changing opcode

----- Original Message ----- > From: "reed kotler" <rkotler at mips.com> > To: llvmdev at cs.uiuc.edu > Sent: Wednesday, February 13, 2013 6:00:45 PM > Subject: [LLVMdev] changing opcode > > Is there a simple way to just change the opcode of a machine > instruction. > > I have a lot of long/short pairs where when I know the offset, i can > replace

On Wed, Feb 13, 2013 at 7:00 PM, reed kotler <rkotler at mips.com> wrote: > Is there a simple way to just change the opcode of a machine instruction. > > I have a lot of long/short pairs where when I know the offset, i can > replace the long version with the short version. > Hey Reed, The x86 target does something like this. Check out ReplaceableInstrs

Hal, that’s a good point. There are more manually-maintained tables in the X86 backend that should probably be tablegened: the memory-folding tables and ReplaceableInstrs, to name a couple. If you have ideas on how to get these auto-generated, please let us know. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev Sent: Wednesday, November 23, 2016

On Tue, Mar 17, 2015 at 6:14 PM, Tim Northover <t.p.northover at gmail.com> wrote: >> As a simplification, the compiler deals almost exclusively in pseudo >> instructions. By x86 analogy, using pseudos to unfold a TEST32rm into >> MOV32rm + TEST32rr means I can skip the complex operand fitting effort >> needed to pick specific machine instructions. There are many

I don't know ARM hardly at all but... This comment does not seem to match the code. Or maybe tBfar is a BL? Also, how does this work if the destination is greater than 2**21? /// fixupUnconditionalBr - Fix up an unconditional branch whose destination is /// too far away to fit in its displacement field. If the LR register has been /// spilled in the epilogue, then we can use BL to

I'm confused as to the logic used in the register scavenger when it cannot find a free register. I would think that it would want to free up the emergency spill slot immediately after it's use, because otherwise there is a chance of needing to use the emergency slot again and not be able to. Instead it tries to restore it only right before register it is freeing up. Maybe I'm

  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,

Hi! I'm making a strange observation in my backend, that ends in illegal code: Version 1: - I lower FrameIndex to TargetFrameIndex (nothing special) - I generate a special address-register ADD instruction in eliminateFrameIndex() to write FramePointer + offset into a new address-register - I use explicit load and store and address-registers in my target instruction patterns: eg (store

Hello LLVM, The ARM target sometimes adds an instruction with a virtual register in eliminateFrameIndex(): https://github.com/llvm-mirror/llvm/blob/master/lib/Target/ARM/ARMBaseRegisterInfo.cpp This looks late for a virtual register to appear. Where is this vreg made real? Thanks, -steve

On 11/18/2013 06:34 PM, Jim Grosbach wrote: > On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > >> I don't know ARM hardly at all but... >> >> This comment does not seem to match the code. >> Or maybe tBfar is a BL? > What does the definition of tBfar say? Okay.. but // Far jump // Just a pseudo for a tBL instruction. Needed

I'm investigating a bug associated with debug information that manifests itself in the XCore backend (PR11105). I'd like to understand what the expected behavior of eliminateFrameIndex() is when it is called on a dbg_value machine instruction. Currently the XCore target replaces the frame index with the frame register and sets the next operand to the byte offset from the frame

On Nov 18, 2013, at 3:49 PM, reed kotler <rkotler at mips.com> wrote: > I don't know ARM hardly at all but... > > This comment does not seem to match the code. > Or maybe tBfar is a BL? What does the definition of tBfar say? > > Also, how does this work if the destination is greater than 2**21? > It doesn’t. IIRC, that’s under the category of “if people start

Hello all, For my custom processor backend I am trying add some instruction using BuildMI() inside eliminateFrameIndex(). I tried RegScavenger like this: unsigned RegUnused0 = RS->FindUnusedReg(&LASER::GNPRegsRegClass); if (!RegUnused0) RegUnused0 = RS->scavengeRegister(&LASER::GNPRegsRegClass, II, SPAdj); assert(RegUnused0 && "Register scavenger failed");

Hello, InstAlias does not allow tied operands (repeated operands) in the asm string to be matched. It seems this situation is explicitly prevented in AsmMatcherEmitter.cpp: if (!Hack) PrintFatalError(TheDef->getLoc(), "ERROR: matchable with tied operand '" + Tok + "' can never be matched!");

Hi Richard, Thanks for working on this! Your patched solved my initial problem, but introduced another one. Please find attached another BC file that fails on xcore with the linear scan regalloc. This is the error message I get eliminateFrameIndex Frame size too big: -3 0 llc 0x08affd1e 1 libc.so.6 0xb7d35a01 abort + 257 2 llc 0x081a0972

I need to use ‘createVirtualRegister’ for a specific case in my ‘eliminateFrameIndex’ function implementation. However, whenever that code is executed, I get the assertion "MachineCopyPropagation should be run after register allocation!” at a later stage. I have seen that at least a couple of backend implementations (including ARM Thumb) create virtual registers in ‘eliminatedFrameIndex’.

Hi, We are currently developing an LLVM target for a micro-controller, and would like our TargetLowering::LowerCall method to emit PUSH instructions (instead of STORE) to pass arguments (which would improve code density for function calls). Is there a way of keeping track of the stack pointer changes implied by the PUSH instruction to calculate the correct offsets in

On Oct 10, 2011, at 10:26 AM, Richard Osborne wrote: > I'm investigating a bug associated with debug information that manifests > itself in the XCore backend (PR11105). I'd like to understand what the > expected behavior of eliminateFrameIndex() is when it is called on a > dbg_value machine instruction. That is up to the target. The TII::emitFrameIndexDebugValue() hook is

Hi Reed, the register scavenger (RS) also keeps track of live registers. This way it "knows" that the register that was spilled/restored far apart is available. Let say you had the following code. You need to find a register to keep vreg1 and vreg2 in. R1 = .... // <- RS current liveness state; we have called RS->forward(It) where It points to here vreg1 = add SP, 1000 ... =

Thanks Jon and Hal for the helpful pointers. By returning true from requiresRegisterScavenging() and requiresFrameIndexScavenging(), LLVM handled all the scavenging effort. That is nearly painless for the target, so why do some targets seem to do scavenging on their own? When the scavenged register is loaded with a simple immediate, is it safe to search the BB and replace other uses of the same