similar to: [LLVMdev] LLVM Register allocation

On Fri, Jan 21, 2011 at 2:48 PM, Vijayaraghavan Murali <m.vijay at nus.edu.sg> wrote: > I just wish to know if other than manually comparing the llc generated > code with the source program, is there any other way of knowing which > variables in the program are mapped to which registers? I was not able > to find any suitable option for the same, so I'm wondering if there is a

Thank you Frits! I noticed the following lines in the dwarf output (run with -O2): .uleb128 40 # Offset .byte 134 # DW_CFA_offset + Reg (6) .uleb128 4 # Offset .byte 135 # DW_CFA_offset + Reg (7) .uleb128 3 # Offset .byte 131 # DW_CFA_offset + Reg (3)

Hello everyone, I have started using LLVM only recently, so I'm a kind of a newbie. I'm using it to observe the effects of our path-sensitive analysis of the source code on register allocation. I just wish to know if other than manually comparing the llc generated code with the source program, is there any other way of knowing which variables in the program are mapped to which

Thanks Lang! Here's another question: I'm trying to process this input: int main() { return 0; } but I'm getting an error Assertion `!Fn.getRegInfo().getNumVirtRegs() && "Regalloc must assign all vregs"' failed. At the start of runOnMachineFunction I call Fn.getRegInfo().getNumVirtRegs(); and find that there is 1 virtual register. However,

I will be removing RegAllocLinearScan and VirtRegRewriter from trunk shortly after we cut the 3.0 release branch. LLVM 3.0 will still ship with the linear scan register allocator, but the default will be the new greedy allocator. Linear scan can be enabled by passing '-regalloc=linearscan -join-physregs' to llc. RegAllocLinearScan and VirtRegRewriter need to go away soon because they

Hi Susan, I'm having trouble reproducing that error on my end, but I think the problem is probably that you're not using the VirtRegRewriter infrastructure. What your allocator needs to do is populate the virtual register mapping (VirtRegMap pass) with your allocation, rather than rewriting the registers directly through MachineRegisterInfo. Have your allocator require and preserve the

Hi again Lang, I decided to try the approach you proposed to see whether it makes the assembly-code problem go away. Again, I tried a very simple register allocator (attached) that just calls vrm.assignVirt2Phys for every vreg in each function, mapping the vreg to the first preg in the register class. I tried two versions: one maps *every* vreg, and the other only maps those for which

I still get a coredump: 0 libLLVM-3.1.so 0x00007f0158a4e67f 1 libLLVM-3.1.so 0x00007f0158a500ca 2 libpthread.so.0 0x0000003a86c0f500 3 libLLVM-3.1.so 0x00007f01583c346c 4 libLLVM-3.1.so 0x00007f0158546349 llvm::FPPassManager::runOnFunction(llvm::Function&) + 521 5 libLLVM-3.1.so 0x00007f01585463e3 llvm::FPPassManager::runOnModule(llvm::Module&) + 51 6 libLLVM-3.1.so

Hi Susan, Sorry - I had missed that you're using llvm-3.1, rather than the development branch. We encourage people to live on top-of-tree - it's well tested, easier for active developers to offer help with, and keeping up with incremental changes is often easier than porting between stable versions. It also sounds like you were building a Release version of LLVM. That will not have any

On May 3, 2011, at 3:24 PM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> On May 3, 2011, at 12:03 PM, David A. Greene wrote: > >>> Certainly. I would ask that we keep linearscan around, if possible, as >>> long as there are significant regressions like this. Our customers tend >>> to really, really care about

Lang - Your version does NOT work for me (i.e., I still get an error from the assembler when I run your code on my tst.c) unless I force compilation and assembly for a 32-bit X86 machine: llc -march=x86 -regalloc=gc tst.bc gcc -m32 tst.s My machine is a 64-bit machine. Maybe you are working with a different architecture and that's why it worked for you? I would be happy if the

Hi Susan, Without debugging symbols I can't make much out of that stack trace I'm afraid. I've attached my modified version of Gcra.cpp. I built llvm 3.1 by dropping this file into lib/CodeGen, and adding references to createGcra to include/lib/CodeGen/Passes.h and include/lib/CodeGen/LinkAllCodeGenComponents.h. (If you search for createRegAllocPBQP you'll see where to add the

Hi, Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the spiller's class? Thanks, -- Silvio Ricardo Cordeiro --------------

My tst.bc is attached. I had to use ssh to copy it from my office machine to my home laptop. In case that corrupts it, I also put a copy here: http://pages.cs.wisc.edu/~horwitz/LANG/tst.bc I created the file like this: clang -emit-llvm -O0 -c tst.c -o tst.bc opt -mem2reg tst.bc > tst.mem2reg mv tst.mem2reg tst.bc Susan On 11/4/2012 3:27 PM, Lang Hames wrote: > Hi Susan, >

On Aug 15, 2010, at 5:12 PM, Silvio Ricardo Cordeiro wrote: > Is there a way for me to collect statistics about the number of loads/stores added by the "linearscan" register allocator (just like can be done with the "local" allocator)? I still haven't grokked very well the interaction between RALinScan and Spiller... Should I add those two statistics to the

Hi Susan, With your bitcode file I am now able to reproduce the issue you're seeing. It looks like this is a problem with the naive rewriting from virtregs to physregs. It appears that the subreg field of physreg operands is ignored post-register allocation. In your testcase %vreg11:sub32 is being rewritten to RBX:sub32, but the :sub32 part is being quietly dropped when the assembly is

On May 3, 2011, at 12:03 PM, David A. Greene wrote: >> >> I am working my way through the regressions, looking for things the >> allocator did wrong. Any help is appreciated, please file bugs if you >> find examples of stupid register allocation. > > Certainly. I would ask that we keep linearscan around, if possible, as > long as there are significant

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > On May 3, 2011, at 12:03 PM, David A. Greene wrote: >> Certainly. I would ask that we keep linearscan around, if possible, as >> long as there are significant regressions like this. Our customers tend >> to really, really care about performance. > > That's reasonable, and it is also useful to keep it

Hi Susan, I tested the version of Gcra.cpp that I sent you on x86-64 systems running MacOS 10.8 and Ubuntu 12.04 (Linux 3.2.0). Could you send me the bitcode file you're compiling? Different bitcodes (due to different clang versions or applied optimizations) could account for the different results we're seeing. For reference I've attached the *.ll file that I have tested with, which

Hi Lang, I looked more into one of the problems I'm now having, and I've attached 3 files: Gcra.cpp is like your version except that for two specific vregs it uses hard-coded pregs instead of the first in the corresponding class. bug1.c is an input that causes the failed assertion for me. If I use the non-debug version of LLVM-3.1 I instead get assembler errors like this: Error: