search for: stackslot

...lvmdev at cs.uiuc.edu > > Sent: Monday, October 13, 2014 8:29:38 AM > > Subject: [LLVMdev] Problem of stack slot coloring > > > > Hi, > > > > > > Can anyone help me with the stack slot coloring optimization? > > This corresponding file is /lib/codegen/stackslotcoloring.cpp. > > > > > > It is said this optimization was for stack slot overlay for frame > > size reduction, after register allocation phase. > > And this transformation pass relies on the LiveStack analysis pass. > > > > > > How, when checking the...

Hi, Can anyone help me with the stack slot coloring optimization? This corresponding file is /lib/codegen/stackslotcoloring.cpp. It is said this optimization was for stack slot overlay for frame size reduction, after register allocation phase. And this transformation pass relies on the LiveStack analysis pass. How, when checking the source code, it seems the LiveStack analysis has not been implemented, since t...

...tead of creating your own stack spot to store %pi into, you should look at the first user of %pi which should be a store of %pi into its stack space, as generated by the static compilation, and pull the stack slot out of there. Something like this: (Given Argument *A to look for:) Value *StackSlot = 0; if (StoreInst *SI = dyn_cast<StoreInst>(*A->use_begin())) StackSlot = SI->getPointerOperand(); though I haven't actually tried to compile or run that. Nick > Paul > > On Sun, May 24, 2009 at 10:15 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nic...

Nick, Thanks for the quick answer. Dereferencing the pointer does yield the same result in both cases but that's not what I want to do. I want to instrument the program dynamically and keep track of certain memory locations which is a problem if the same variable has different addresses for the static/dynamic code - as far I see this is what it's happening but I have no clue why. Paul On

...ack > spot to store %pi into, you should look at the first user of %pi which > should be a store of %pi into its stack space, as generated by the > static compilation, and pull the stack slot out of there. Something like > this: > > (Given Argument *A to look for:) > Value *StackSlot = 0; > if (StoreInst *SI = dyn_cast<StoreInst>(*A->use_begin())) > StackSlot = SI->getPointerOperand(); > > though I haven't actually tried to compile or run that. > > Nick > > > Paul > > > > On Sun, May 24, 2009 at 10:15 PM, Nick Lewycky...

> 1) Some machine instructions have implicit register operands. If you are > not including these in your calculations you will probably have some errors. > My apologies for not mentioning this earlier. > > You can find the set of implicit uses and defs by querying the > TargetInstDesc object for each MachineInstr (call MachineInstr::getDesc() to > get it, and then the

...{ %1 = tailcall b() ret %1 } i32 b() { %1 = tailcall c() ret %1 } i32 c() { %1 = tailcall d() ret %1 } i32 d() { ret i32 5 } only d() will actually perform the return i.e the move of the result to register %eax on x86 or in case of a struct return the move to whatever registers/(stackslots?) are used to return the elements of the struct. regards arnold

...t;imp-def,dead> DoReMat = 1, SSorRMId = 262152 PhysReg R12 clobbered, invalidating SS#170 Remembering RM#8 in physreg R12 %R12<def> = MOV64ri64i32 32 ; srcLine 0 %reg2563<def> = SUB64rr %R12, %RBX, %EFLAGS<imp-def,dead> ; srcLine 0 Processing def operand %reg2563<def> StackSlot for def = 165 Store: MOV64mr <fi#165>, 1, %reg0, 0, %R12<kill> ; srcLine 0 PhysReg R12 clobbered, invalidating RM#8 Remembering SS#165 in physreg R12 ##### Good, it got the remat for %reg2563. It goes on to process the spill of %reg2563 after the SUB64: ##### Processing instruction...

I've been playing around with spillers and found that the SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT) 00186 return true; 00187 // Split register can be assigned a physical register as well as a 00188 // stack slot or remat id. 00189 return (Virt2SplitMap[virtReg] && Virt2Phys...

Justin, We have the same issue with the AMDIL code generator. We tried #1, but there are passes after register allocator that don't like virtual registers. #3 could be done by having the two spill functions [load|store]Reg[From|To]StackSlot keep track of the FrameIndex to register mapping internally, but again, more of a hack than a proper solution. My solution was to just create a very large register file, 768 registers, that no sane kernel would ever reach and then do register allocation within that. A simple script that is run at...

...ost correct. MCRegisters can only be invalid ($noreg) or physical registers. The lack of support for vregs is indicated by the lack of any vreg API's while the lack of support for stack slots is indicated by the lack of all (except one) stack slot API's and is mentioned in a comment: "StackSlot values do not exist in the MC layer, see Register::isStackSlot() for the more information on them." The reason there's still an MCRegister::isStackSlot() function despite that is an implementation detail. The checks for invalid and phys reg historically tested for ==0 and >0 respective...

Hi Susan, > 1. I tried running the PBQP allocator (as a dynamic pass), but that didn't > work.... Can you tell from this what I'm doing wrong? > The PBQP allocator is built into the LLVM CodeGen library, so the "-regalloc=pbqp" option is already available in llc. If you've built a copy of the PBQP allocator in a separate library it will try to re-register

...orrect. MCRegisters can only be invalid ($noreg) or physical registers. The lack of support for vregs is indicated by the lack of any vreg API's while the lack of support for stack slots is indicated by the lack of all (except one) stack slot API's and is mentioned in a comment: > "StackSlot values do not exist in the MC layer, see Register::isStackSlot() for the more information on them." > > The reason there's still an MCRegister::isStackSlot() function despite that is an implementation detail. The checks for invalid and phys reg historically tested for ==0 and >0...

On Tuesday 24 February 2009 14:54:12 Arnold Schwaighofer wrote: > Whether it will be more efficient i can't answer off hand. Sorry. But > probably not because the code generated should be quite similar. > > For the sret version the move of the result is performed before the return. > store { i8*, i8* } %15, { i8*, i8* }* %19 > ret i32 0 > > For the struct return

...ret %1 > } > > i32 c() { > %1 = tailcall d() > ret %1 > } > > i32 d() { > ret i32 5 > } > > only d() will actually perform the return i.e the move of the result > to register %eax on x86 or in case of a struct return the move to > whatever registers/(stackslots?) are used to return the elements of > the struct. Right but if only d() performs the move then what is going on between the tail calls and the returns in a, b, and c that inhibits TCO? I thought they might be redundant moves (but I've no idea!). -- Dr Jon Harrop, Flying Frog Consultan...

...ct. MCRegisters can only be invalid ($noreg) or physical registers. The lack of support for vregs is indicated by the lack of any vreg API's while the lack of support for stack slots is indicated by the lack of all (except one) stack slot API's and is mentioned in a comment: >> "StackSlot values do not exist in the MC layer, see Register::isStackSlot() for the more information on them." >> >> The reason there's still an MCRegister::isStackSlot() function despite that is an implementation detail. The checks for invalid and phys reg historically tested for ==0 an...

...spillers and found that the > SimpleSpiller fails > badly on a particular code. > > The problem arises because SimpleSpiller does the test > VRM.isAssignedReg(virtReg) which is implemented as: > > 00183 bool isAssignedReg(unsigned virtReg) const { > 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && > 00185 getReMatId(virtReg) == NO_STACK_SLOT) > 00186 return true; > 00187 // Split register can be assigned a physical register as > well as a > 00188 // stack slot or remat id. > 00189 return (Virt2SplitM...

...! My generated code is spilling correctly but is not reloading at all. For example, if the original code has the equivalent of this (where %1024 is a virtual reg): %1024 = xxx ... yyy = %1024 and I find no physical register for %1024, then I assign it to physical register %edi and to a stackslot. That creates code like this: %edi = xxx store from %edi to the stack ... yyy = %edi The last instruction is wrong. There needs to be a load from the stackslot into %edi before copying from there into yyy. The documentation says: If the indirect strategy is used, after all the virtu...

...findPrologueEndLoc will return the wrong result if the flag isn't consistently set on frame setup code. The problem is that unless you override TargetFrameLowering::spillCalleeSavedRegisters, then PrologEpilogInserter will just spill callee saved registers through a series of calls to storeRegToStackSlot. This is fine, except storeRegToStackSlot won't set the FrameSetup flag. [1]: Actually X86 will only skip over PUSH instructions with the FrameSetup flag. Is this extra condition necessary? ## Potential solutions 1) Keep the status quo, but modify PrologEpilogInserter so it will mark the la...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more