similar to: VirtRegMap invariant: no reserved physical registers?

Displaying 20 results from an estimated 1000 matches similar to: "VirtRegMap invariant: no reserved physical registers?"

2008 May 28
3
[LLVMdev] Possible VirtRegMap Bug
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)
2012 Oct 31
3
[LLVMdev] problem trying to write an LLVM register-allocation pass
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,
2012 Nov 01
2
[LLVMdev] problem trying to write an LLVM register-allocation pass
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
2012 Nov 01
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
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
2012 Nov 01
2
[LLVMdev] problem trying to write an LLVM register-allocation pass
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
2012 Nov 01
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
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
2012 Nov 05
2
[LLVMdev] problem trying to write an LLVM register-allocation pass
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:
2012 Nov 04
3
[LLVMdev] problem trying to write an LLVM register-allocation pass
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, >
2012 Nov 03
2
[LLVMdev] problem trying to write an LLVM register-allocation pass
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
2012 Nov 11
2
[LLVMdev] problem trying to write an LLVM register-allocation pass
Hi Susan, It looks like the bitcode you have attached is corrupted. You should make sure to attach it as a binary file. Alternatively you can attach the LLVM assembly as text. You can generate an assembly file from bitcode with: llvm-dis -o <asm file> <bitcode> Regards, Lang. On Fri, Nov 9, 2012 at 11:15 AM, Susan Horwitz <horwitz at cs.wisc.edu> wrote: > Thanks Lang,
2012 Nov 08
2
[LLVMdev] problem trying to write an LLVM register-allocation pass
Hi Susan, In x86-64 the REX prefix must be used to access an extended register (r8-r15 and their aliases), but cannot be used when accessing the high byte of the ABCD regs (AH, BH, CH, DH). In your test case you have hardcoded %vreg1 to R8B, and %vreg15 to AH, and the test case contains a copy between these registers. The copy simultaneously must have a REX prefix, and cannot have a REX prefix,
2012 Nov 05
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
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
2012 Nov 11
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
Sorry about that. I created the assembly file and attached it (as math.txt). Susan On 11/11/2012 12:41 AM, Lang Hames wrote: > Hi Susan, > > It looks like the bitcode you have attached is corrupted. You should > make sure to attach it as a binary file. Alternatively you can attach > the LLVM assembly as text. You can generate an assembly file from > bitcode with: > >
2012 Nov 01
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
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
2012 Nov 07
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
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
2012 Nov 13
5
[LLVMdev] problem trying to write an LLVM register-allocation pass
Hi Susan, The problem is that the allocator is re-using the 'preg', which is calculated for an operand that may have a subreg index, for loads and stores to a stack-slot. The stack slot always has the same width as vreg (which is the right behavior), but for operands with subreg indexes, 'preg''s class will be different from 'vreg', in which case you get the mismatched
2007 Aug 06
5
[LLVMdev] Spillers
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
2012 Nov 04
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
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
2012 Nov 09
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
Thanks Lang, we are making progress! I no longer get the failed assertion, but the code I'm using for vregs that don't get allocated a preg, and thus need to be spilled and re-loaded is causing assembler errors. I suspect the problem is my code for allocating space in the stack, but I don't know how to fix it. I've attached a new version of the simple register-allocation
2012 Nov 13
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
Lang - Your fix does prevent the assembler errors, but it doesn't seem to produce correct assembly. I created a slightly modified version that, for each instruction that includes a vreg, adds a check that the preg selected is not already in that instruction. I've attached that version. I think that this version of Gcra.cpp should produce correct assembler, since it's allocating