search for: assignvirt2phi

Hey all, I've found a bug in either the PBQP register allocator or in VirtRegRewriter. I'm observing this assertion in VirtRegRewriter::rewrite() fail: unsigned VirtReg = MO.getReg(); unsigned PhysReg = VRM->getPhys(VirtReg); ... assert(!MRI->isReserved(PhysReg) && "Reserved register assignment"); Indeed there is a case where

I'm having no luck getting my register allocator to work. I'm trying to do it using the "indirect" approach; i.e., using a VirtRegMap, with calls to assignVirt2Phys, assignVirt2StackSlot, etc. and a call to a "spiller" at the end. As a warm-up exercise (before implementing register allocation via graph coloring) I'm trying to implement a very simple scheme in

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)

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

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

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

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

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

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,

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

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 Fernando, --- Fernando Magno Quintao Pereira <fernando at cs.ucla.edu> wrote: > > Hi, Roman, > > maybe I can try to answer this. I think that all boils down to > having register to reload spilled values. Ok. That I can follow. > Once a register is spilled, its live range is split into smaller > pieces. These pieces most be contained into registers, and

Hi Susan, > But this doesn't seem to be happening; the stores to memory are there but > the loads are not. > > Any ideas what's going wrong? Are you using VirtRegMap::addSpillPoint and VirtRegMap::addRestorePoint ? If not you may need to add calls to them to let the rewriter know where to insert the loads/stores. > If not, any advice on how to generate the loads

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

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

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

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

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

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:

Hi Susan, Sorry for the delayed response. Thanks for the test cases - I'm looking in to this now. - Lang. On Mon, Nov 5, 2012 at 2:58 PM, Susan Horwitz <horwitz at cs.wisc.edu> wrote: > 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