similar to: [LLVMdev] register scavenger

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

CC the list. On Sat, Nov 10, 2012 at 6:30 PM, Arnold Schwaighofer <arnold.schwaighofer at gmail.com> wrote: > Assuming you use the scavenger in your own code yes. > > A usage could look like: > > for all basic blocks BB: > RS->enter(BB) > for all instructions CurrInst in block order: > if CurrInst has virtual def > CurrReg = RS->scavenge(CurrInst)

You mean when I "explicity" use it by calling methods of register scavenger? Right now I'm just allocating virtual registers that will be resolved by the use of register scavenger and I'm also providing an override of the virtual method saveScavengerRegister. In Mips16, I have an extra mips 32 register (not usually very useful since it can only be used in a move instruction)

I ran into another issue with register scavenger. In my case, I don't need a place on the stack for an emergency spill slot. I have these free mips32 registers, that are not in general very useful for other things, for the emergency spill slot. I can move to and from mips16 (subset of mips32) registers and mips32 registers. I also have a situation where I need two free registers so then

Hi All, I'm dealing with a problem where the spill/restore instructions inserted during scavenging span an adjustment of the SP/FP register. The result is that despite the base register (SP/FP) being changed between the spill and the restore, both store and load use the same immediate offset. I see code in the PEI (replaceFrameIndices) that is supposed to track the SP/FP adjustment:

CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when replaceFrameIndices are run. Evan On Sep 25, 2013, at 8:57 AM, Krzysztof

Consider this example: --- ex.ll --- declare void @bar() ; Function Attrs: nounwind optsize define void @main() { entry: %hin = alloca [256 x i32], align 4 %xin = alloca [256 x i32], align 4 call void @bar() ret void } ------------- Freshly built llc: llc -O2 -march=x86 < ex.ll -print-before-all # *** IR Dump Before Prologue/Epilogue Insertion & Frame Finalization ***: #

The code has changed a lot over the years. Looks like at some point of time the assumption was broken. calculateCallsInformation() may have eliminated the pseudo set up instructions already. // If call frames are not being included as part of the stack frame, and

Thanks, I'll look into that. Still, the case where the function does not call anything remains---in such a situation there are no ADJCALLSTACK pseudos, so regardless of what that function you pointed at does, there won't be any target-independent information about the SP adjustment by the time the frame index elimination runs. Would it make sense to have ADJCALLSTACK pseudos every

Hi! During my backend development I get the error message for some tests: *** Bad machine code: Virtual register def doesn't dominate all uses. *** (C source-code, byte-code disassembly and printed machine code at the end of the email) The first USE of vreg4 in BB#1 has no previous DEF in BB#0 or #1. But why? I can't see how the LLVM byte-code is transformed to the lower machine code.

Hi Quentin, yes, this happens quite late. With the Option --debug-pass=Structure it's in or after "Assembly Printer". I do have a very simple DAGToDAGISel::Select() method: SDNode *MyTargetDAGToDAGISel::Select(SDNode *N) { SDLoc dl(N); // default implementation if (N -> isMachineOpcode()) { N -> setNodeId(-1); return NULL; // Already selected. } SDNode

Hi Quentin, I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I found out, that some SDNodes are not passed to the ::Select(SDNode*N), approximately 11 nodes are missing. The first add-node (v1+v2) is missing. Is it normal that not all nodes are passes to ::Select()? Thanks,

Hi, I wanted to see the non-debug uses of register 0 (Noreg) and so, I wrote the following piece of code. ***** MRI = &MF.getRegInfo(); if (!MRI->use_nodbg_empty(0)) { for (MachineRegisterInfo::use_nodbg_iterator ri = MRI->use_nodbg_begin(0), re = MRI->use_nodbg_end(); ri != re; ++ri) { MachineInstr *UseMI = &*ri; UseMI->dump ();

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

On 1/29/15 2:00 PM, Steve King wrote: > 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? The register scavenger should take care of such

Hi Quentin, Am 01.11.2014 um 00:39 schrieb Quentin Colombet <qcolombet at apple.com>: > > On Oct 31, 2014, at 11:00 AM, Boris Boesler <baembel at gmx.de> wrote: > >> Hi Quentin, >> >> I added some debug output (N->dump()) in ::Select(SDNode*N) and compared it to the dot/Graphviz output (-view-legalize-types-dags; the last one with correct code). I

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

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");

Add GS base to the HVM VCPU context returned by xc_vcpu_getcontext() Signed-off-by: Aravindh Puthiyaparambil <aravindh@virtuata.com> diff -r e62ab14d44af -r babbb3e0f4d3 xen/arch/x86/domctl.c --- a/xen/arch/x86/domctl.c Fri Apr 20 11:36:02 2012 -0700 +++ b/xen/arch/x86/domctl.c Fri Apr 20 17:55:49 2012 -0700 @@ -1592,6 +1592,12 @@ void arch_get_info_guest(struct vcpu *v,

----- Original Message ----- > From: "Steve King" <steve at metrokings.com> > To: jonathan at codesourcery.com > Cc: llvmdev at cs.uiuc.edu > Sent: Friday, January 30, 2015 10:52:19 AM > Subject: Re: [LLVMdev] creating a vreg in eliminateFrameIndex() > > Thanks Jon and Hal for the helpful pointers. By returning true from > requiresRegisterScavenging() and