similar to: [LLVMdev] Problem of stack slot coloring

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

So what addIntervalsToSpills returns are new intervals to allocate with infinite weights, right? And I need not to allocate the old interval. Should hasStackSlot return true on its register then? On 8/21/06, Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > > Well, someone correct me if am wrong, but, you still have to allocate > physical registers to them,

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

> So what addIntervalsToSpills returns are new intervals to allocate with > infinite weights, right? > And I need not to allocate the old interval. Should hasStackSlot return true > on its register then? > I am not very sure about addIntervalsToSpill, but, for all the registers created to replace a spilled registers, they must have a stack slot assigned to them. I am sending you my

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

Can someone explain the theory behind the spillers in VirtRegMap.cpp? It seems as though the spillers do triple duty: - Insert load/store operations and/or fold instructions as necessary to carry out spills - Rewrite the spilled virtual registers to use machine registers (mapping given by the caller in the VRM). - Rewrite machine code to change virtual registers to physical registers

On Jun 4, 2010, at 3:05 AM, Sylvere Teissier wrote: > > In my target the CALL instruction change the link Register %LR > In the target InstrInfo.td I have "Defs=[LR]" on the CALL instruction > definition to handle that. So your CALL instructions are clobbering your callee-saved registers, eh? ;-) > It works well with others registers allocators: when there is a call

Hi, Three new files added: lib\Analysis\ValueTracking.cpp lib\CodeGen\StackSlotColoring.cpp lib\CodeGen\LiveStackAnalysis.cpp Regards, Cédric -------------- next part -------------- A non-text attachment was scrubbed... Name: updVS2005prj.patch Type: application/octet-stream Size: 1064 bytes Desc: not available URL:

> 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

Thanks again. I executed the following command line llc -O3 comb.ll.bc -debug-pass=Arguments and got Pass Arguments: -targetdata -targetpassconfig -no-aa -tbaa -targetlibinfo -basicaa -collector-metadata -machinemoduleinfo -machine-branch-prob -preverify -domtree -verify -loops -loop-simplify -scalar-evolution -loop-simplify -iv-users -loop-reduce -gc-lowering -unreachableblockelim

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

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias

Hi Quentin, On 08/19/14 18:58, Quentin Colombet wrote: [...] > It seems that you will have to debug further the *** Bad machine code: Instruction loads from dead spill slot *** before we can be of any help. Yes, I've done some more digging. Sorry for the long mail... I get: Inline spilling aN40_0_7:%vreg1954 [5000r,5056r:0)[5056r,5348r:1) 0 at 5000r 1 at 5056r At this point I have

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

On Feb 20, 2008, at 7:36 PM, David A. Greene wrote: > On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > >>> In other words, after coalescing, should it be the case that >>> subregister >>> intervals contain at least all of the range information that was >>> contained >>> in any eliminated intervals when those eliminated intervals were

On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > > In other words, after coalescing, should it be the case that > > subregister > > intervals contain at least all of the range information that was > > contained > > in any eliminated intervals when those eliminated intervals were > > coalesced > > to the subregister's superregister? >

Hi, > I executed the following command line > > llc -O3 comb.ll.bc -debug-pass=Arguments > > and got > > Pass Arguments: -targetdata -targetpassconfig -no-aa -tbaa > -targetlibinfo -basicaa -collector-metadata -machinemoduleinfo > -machine-branch-prob -preverify -domtree -verify -loops -loop-simplify > -scalar-evolution -loop-simplify -iv-users -loop-reduce

Hello, I've been trying to figure out how to reproduce the results of a single clang -O3 compilation to a binary with a multi-step process using opt. Specifically I have: clang -O3 foo.c -o foo.exe which I want to replicate with: clang -O0 -c -emit-llvm foo.c opt -O3 foo.bc -o foo_o.bc clang foo_o.bc -o foo.exe Any hints / suggestions on what additional flags I need to produce the same

Awesome, thanks! I'd like to have the last step (llc in your example) not perform additional optimization passes, such as O3, and simply use the O3 pass from opt in the previous line. Do you happen to know if I should use 'llc -O0 foo_o.bc -o foo.exe' instead to achieve this? On Thu, Jul 2, 2020 at 6:35 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Thu,