similar to: [LLVMdev] Fast register allocation

Hello LLVM developers, I have a few questions regarding the passes that are run after instruction selection and before register allocation. I am writing a scheduling pass (modulo scheduling). Before I ask my questions, I will first try to explain the approach I am taking. - Currently, I am running the passes in the following order. (-debug-pass=Structure output) Remove unreachable machine

Dear guys, I am in need of more of your help. I'm implementing a register allocator, and I am having problems to make it produce correct code. Consider this program here: int main(int argc, char ** argv) { int i, j, sum; i = argv[0][0]; j = argv[0][1]; sum = (i + j) * j; printf("Sum = %d\n", sum); } that maps to this llvm bytecode: entry (0xa785590, LLVM

I am wondering about register allocation when there is a kill flag on the MachineOperand. Do I need to remove the kill flag? This code below is just an example from test\CodeGen\X86\xor.ll # Machine code for function test3: Frame Objects: fi#-2: size=4, align=4, fixed, at location [SP+8] fi#-1: size=4, align=8, fixed, at location [SP+4] Function Live Outs: %EAX BB#0: derived from LLVM BB

The following is the code fragment after "# *** IR Dump Before Prolog/Epilog Insertion & Frame Finalization ***:". * MOV32mi <fi#2>, 1, %reg0, 0, %reg0, 0 * * MOV32mr <fi#2>, 1, %reg0, 0, %reg0, %ECX<kill>* * %EAX<def> = MOV32rm <fi#2>, 1, %reg0, 0, %reg0* * MOV32mr %reg0, 1, %reg0, <ga:@one+4>, %reg0, %EAX<kill>* * %EAX<def> = MOV32rm

Oops. Forgot the mailing list in the reply. -- Arnaud de Grandmaison ________________________________________ From: Arnaud Allard de Grandmaison Sent: Thursday, June 03, 2010 9:57 PM To: Jakob Stoklund Olesen Subject: RE: [LLVMdev] Unused argument registers can not be reused ? I have finally been able to make some progress : the bug has been introduced/revealed by svn commit #95493, which enabled

I have tested the register allocation in llvm, using: $llc -debug test.bc where, test.c is like: int a, b, c, d, x; a = 3; b = 5; d = 4; x = 100; if ( a > b ) ...... And I got the machine code before register allocation: MOV32mi <fi#2>, 1, %reg0, 0, %reg0, 3; mem:ST4[%a] MOV32mi <fi#3>, 1, %reg0, 0, %reg0,

Hi LLVMdevs, I am trying to get the runtime values of variables (parameters and local variables) in a function running in JIT mode. I generated intrinsic calls to obtain the values of some variables as shown in the definition below. define void @foo(i32 %arg1) { entry: %X = alloca i32, !dbg !3 store i32 21, i32* %X, !dbg !3 %Y = alloca i32, !dbg !3 store i32 22, i32* %Y, !dbg !3

While migrating my codebase from llvm-2.6 to llvm-2.7, I found a different behaviour in the register allocation. I have been able to reproduce it using the msp430 backend, with the 2.7 release as well as the svn head. For the msp430, the first four parameters of a function are passed thru registers. What I observe is that if those parameters are not used inside the function, those registers can

On Sep 3, 2008, at 5:58 AM, Lang Hames wrote: > Hi LLVMers, > > I have finally sorted out licensing issues and found some time, so I'm > trying to port my PBQP register allocator to 2.4 in order to Nice! We would definitely welcome your contribution. > > contribute it (if you want it). I've run into a bug that has me > confused though. > > I'm currently

Any ideas? Instruction uses an alias of an allocated register UNREACHABLE executed at RegAllocFast.cpp:358! 0 clang 0x0000000101309bc2 PrintStackTrace(void*) + 34 1 clang 0x000000010130a863 SignalHandler(int) + 707 2 libSystem.B.dylib 0x00007fff8056935a _sigtramp + 26 3 libSystem.B.dylib 000000000000000000 _sigtramp + 2141809856 4 clang 0x00000001012dd96d

Hi LLVMers, I have finally sorted out licensing issues and found some time, so I'm trying to port my PBQP register allocator to 2.4 in order to contribute it (if you want it). I've run into a bug that has me confused though. I'm currently failing the following assertion: llc: VirtRegMap.cpp:1733: void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&,

Hi, I want to know what is the type or size of a virtual register in a Machineinstr::MachineOperand (If this MachineOperand is a register). For example, what is the size of reg16385 in the following MachineInstr. I know now in the llvm bitcode, the type of a Instruction could be obtained from the Value::GetType(), but what is the counterpart in MachineInstr (not derived from class Value)?

Hello, i've noticed a new possible missed optimization while testing more trivial code. This time it's not a with a xor but with a multiplication instruction and the example is little bit more involved. C code: typedef short t; t foo(t a, t b) { t a4 = a*b; return a4; } argument "a" is passed in R15:R14, argument "b" in R13:R12, the return value is stored in

Chris Lattner wrote: > On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote: >>> That should work fine, just use "jit" instead of "x86-emitter" as the >>> debug type. >> That's impossible: CurrentDebugType is now private; it appears >> nowhere in the installed headers. I can't find any public interface >> to allow a JIT to set it. >

> > It seems to me that the only instructions > > with dead definitions that I should not remove are the calls. Is it true? > > I would like to know if a code like this below is safe, that is, besides > > call instructions, is there other instructions that must stay in the code > > even if their definitions are dead? > > > > MachineInstr * mi = iter; >

A physical register cannot be live across the block. So it must have a use in the block or it must be marked dead. From your dump, it looks like the CCFLAGS defs are not being marked dead. It's unclear where things went wrong, but you can step through LiveVariables to debug this. Evan On Jan 9, 2009, at 2:50 AM, Christian Sayer wrote: > Hello, > > For my backend, I define and

Hello, For my backend, I define and use a CC register similiarly to the EFLAGS register in X86 (I call it CCFLAGS). But if I make all arithmetic/logic instructions affect it ('let Defs = [CCFLAGS] in...' in InstrInfo.td) I run into // The only case we should have a dead physreg here without a killing or // instruction where we know it's dead is if it is live-in to the function

Ok, I've been tracking down a remat bug for over a week. I think I finally understand what is going on. This happens in specfp2006 leslie3d compiled with our frontend and optimizer. Unfortunately, getting a testcase is going to be impossible due to restrictions on SPEC redistribution and the complexity of the sequence of events leading to the bug. The bug is extremely subtle and nasty.

Evan, >A physical register cannot be live across the block. So it >must have a use in the block or it must be marked dead. From >your dump, it looks like the CCFLAGS defs are not being marked >dead. It's unclear where things went wrong, but you can step >through LiveVariables to debug this. Thanks for your response. I did quite some stepping through the llc passes, and it

Hi all, When compiling some programs using the Mips backend i'm getting this assert message on lib/CodeGen/LiveInterval.cpp:227: "Range is not entirely in interval!" I don't know yet if it's something that is missing on the backend code or why the range to be removed it outside the interval, does anyone have any clue? A more detailed output is attached. The program i tried