similar to: [LLVMdev] how to change one operand of an LLVM instruction

Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] how to change one operand of an LLVM instruction"

2008 Jul 24
3
[LLVMdev] Irreducible CFG from tail duplication
It seems that tail duplication can make a reducible CFG irreducible (example below). Is that intentional? Are there other optimizations that have that property? Is irreducibility a problem for existing LLVM passes? It looks like there was once an open project for a pass to make irreducible graphs reducible. Was that ever implemented? - Mark ; "opt -inline -tailduplicate" makes an
2008 Jul 24
0
[LLVMdev] Irreducible CFG from tail duplication
On Thu, Jul 24, 2008 at 2:00 PM, Mark Leone <markleone at gmail.com> wrote: > Is irreducibility a problem for existing LLVM passes? There aren't any LLVM passes that expect a reducible CFG at the moment; of course, some passes are more effective with reducible CFGs. > It looks like > there was once an open project for a pass to make irreducible graphs > reducible. Was that
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
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 15
5
[LLVMdev] problem trying to write an LLVM register-allocation pass
I tried using this flag and it gave me errors on code that otherwise assembles and runs just fine (using the version of Gcra.cpp that Lang wrote). So I'm wondering if I should really be using the flag? I'm using it like this: llc -verify-machineinstrs -load Debug/lib/P4.so -regalloc=gc xxx.bc Susan On 11/15/2012 01:13 PM, Jakob Stoklund Olesen wrote: > > On Nov 15, 2012, at
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 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 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 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 14
1
[LLVMdev] problem trying to write an LLVM register-allocation pass
Hi Susan, The problem now is the usedPregSet. Take the instruction: %vreg13:sub_32bit<def> = ADD32rr %vreg13:sub_32bit, %EAX<kill>, %EFLAGS<imp-def,dead> %EAX will be added to usedPregSet when the instruction is encountered, but %vreg13 is a different class (64bit registers), so none of its candidates will conflict. In addition to checking membership of usedPregSet, you need
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 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 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
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 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 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 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 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 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 16
0
[LLVMdev] problem trying to write an LLVM register-allocation pass
Hi Susan, Jakob pointed out to me that the Gcra.cpp allocator doesn't record basic-block live-ins, which are used by the verifier to check correctness. You can record which variables are live into a basic block with MachineBasicBlock::addLiveIn(unsigned physReg). I don't know the verifier well, but if it's using other built in infrastructure for register allocation then it may not be