search for: stackslots

Hal's advice helps me a lot to understand the implementation much better. Thanks so much! So, now I am able to state my problem more clearly: 1) There are two kinds of locals, i.e., the local variables originated from the source code (like C/C++), and the compilation generated temporaries. After instruction selection phase, the former is seen as frame indexes, while the latter is seen as

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

Paul Martin wrote: > > 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

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

Nick, Your solution works well if there is a store instruction in the function but in the case where there is none (i.e. the argument is passed on directly to another function), creating a store does not help to get the memory address of the variable which takes me back to my initial question at http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022590.html - isn't there a way to obtain the

> 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

Ok, I've been tracking down a remat bug for over a week. I think I finally understand what is going on. This happens in specfp2006 leslie3d compiled with our frontend and optimizer. Unfortunately, getting a testcase is going to be impossible due to restrictions on SPEC redistribution and the complexity of the sequence of events leading to the bug. The bug is extremely subtle and nasty.

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)

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

> On 29 Sep 2020, at 09:28, Quentin Colombet <qcolombet at apple.com> wrote: > > + Daniel who added the MCRegister class. > > Ah sorry, I replied too fast. > I mixed up MCPhysReg with MCRegister. > > I was not aware we had such class. > > From a look at it, MCRegister are essentially the same thing as Register. I am guessing that the difference is Register

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

Yes so long as you're including the invalid space too (IIRC it matters for DBG_VALUE in particular) the reason I didn't do that is that there's a lot more ctors than consumers of MCRegister. It seemed cheaper to do the checks when they're consumed and pretty much every consumer I encountered started with `assert(Reg.isPhysicalRegister() && ...)`. > On 29 Sep 2020, at

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

> On 29 Sep 2020, at 11:13, Mircea Trofin <mtrofin at google.com> wrote: > > > > On Tue, Sep 29, 2020 at 11:09 AM Daniel Sanders <daniel_l_sanders at apple.com <mailto:daniel_l_sanders at apple.com>> wrote: > Yes so long as you're including the invalid space too (IIRC it matters for DBG_VALUE in particular) the reason I didn't do that is that

On May 27, 2008, at 5:36 PM, David Greene wrote: > 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

I found the problem! 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

## Problem description One of the responsibilities of a target's implementation of TargetFrameLowering::emitPrologue is to set the frame pointer (if needed). Typically, the frame pointer will be stored to the stack just like the other callee-saved registers, and emitPrologue must insert the instruction to change its value after it was stored to the stack. Mips does this by looking at the

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