similar to: Help Required llc runtime error for simple MachineFunctionPass

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

Welcome to the world of pluggable machine passes. This work was done to lighten the load of some llvm tools, ie., only link in the register allocators and instruction schedulers that are actually needed in a particular circumstance. I guess I will have to write this up, but generally it works like this. In your register allocator .cpp file add the following include; #include

> On Dec 17, 2008, at 4:53 AM, Mark Shannon wrote: >> Choosing the fast selector does speed code-generation by almost >> double, >> when using llc, but the reduction in final code speed is obviously a >> downside. > [...] >> Since my toolkit generates an interpreter, I am able to just compile >> hotspots, so final speed of compiled code is quite

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,

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

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

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

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

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

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

I found this with LLVM 2.3 and reproduced with svn as of about thirty minutes ago and they both fail in the same way. If you run this code through opt -instcombine define fastcc i64 @fibo(i64) { switch i64 %0, label %2 [ i64 0, label %8 i64 1, label %8 ] ; <label>:2 ; preds = %1 %3 = sub i64 %0, 1 ; <i64> [#uses=1] %4 = call i64 @fibo(i64 %3) ; <i64> [#uses=1] %5 =

v2: use initialization list (Pierre) Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> Reviewed-by: Pierre Moreau <pierre.morrow at free.fr> --- src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp

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,

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

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

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp index 9d70ec3c9c..e4f38c8e46 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp +++

Dear Anton, you can add your register allocator strait iin the "lib/CodeGen/Passes.cpp", and then 're-make' it: "makellvm llc", on the top of lib/CodeGen. It is faster than running make from LLVMOBJDIR. The problem is that it only add to llc the changes on the lib/CodeGen directory. If you change other parts, a make from LLVMOBJDIR will synchronize it. Try adding

It looks like this patch was never merged. You could initialise “nodeCount” and “nodes” directly in the member initialisation list. With that changed, this patch is Reviewed-by: Pierre Moreau <pierre.morrow at free.fr> On 2017-08-12 — 01:45, Tobias Klausmann wrote: > Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> > --- >