similar to: [LLVMdev] Live Intervals Question

On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp- > def,dead>, > %RDX<imp-def,dead>, %RSI<imp-def,dead>, %RDI<imp-def,dead>, >

Evan, thanks for responding so quickly. On Tuesday 26 June 2007 14:11, Evan Cheng wrote: > On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > > 32 CALL64pcrel32 <ga:printf>, %RDI<kill>, %RAX<imp-def>, %RCX<imp- > >

On Jun 26, 2007, at 12:57 PM, David Greene wrote: > Evan, thanks for responding so quickly. > > On Tuesday 26 June 2007 14:11, Evan Cheng wrote: >> On Jun 26, 2007, at 11:20 AM, David A. Greene wrote: >>> 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> >>> MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> >>> 32 CALL64pcrel32

On Jun 26, 2007, at 12:11 PM, Evan Cheng wrote: > AH,inf = [30,42:0)[50,54:1) 0@? 1@? > AL,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2@? > AX,inf = [30,42:0)[50,54:1) 0@? 1@? > EAX,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2 at 50 > RAX,inf = [34,50:0)[50,54:1) 0@? 1 at 50 > > AL is marked dead. So it makes sense there is a gap between [30:31) > and

On Tuesday 26 June 2007 14:57, David Greene wrote: > > EAX and its sub-registers are defined by the MOV8rr instruction > > > > implicitly: > > > 28 %AL<dead> = MOV8rr %reg1024<kill>, %EAX<imp-def> > > > MOV8rr %mreg(2)<d> %reg1024 %mreg(17)<d> > > > > So their live ranges start at 28+2. > > Yep, this makes sense

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

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

On Tuesday 26 June 2007 14:13, Evan Cheng wrote: > On Jun 26, 2007, at 12:11 PM, Evan Cheng wrote: > > AH,inf = [30,42:0)[50,54:1) 0@? 1@? > > AL,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2@? > > AX,inf = [30,42:0)[50,54:1) 0@? 1@? > > EAX,inf = [30,31:0)[34,42:1)[50,54:2) 0 at 30 1@? 2 at 50 > > RAX,inf = [34,50:0)[50,54:1) 0@? 1 at 50 > > > >

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

On Wed, 9 Jun 2004, Vladimir Prus wrote: > Chris Lattner wrote: > > > Thanks, this works! I don't yet understand why spill code is needed there > > > at all, but I'll return to that when I have branches working correctly. > > > > I'm not sure either. Can you send the code before and after register > > allocation? > > Attached. Okay, yeah

Chris Lattner wrote: > > Thanks, this works! I don't yet understand why spill code is needed there > > at all, but I'll return to that when I have branches working correctly. > > I'm not sure either. Can you send the code before and after register > allocation? Attached. > You might also try -regalloc=linearscan, as the default > allocator is, uhhh,

It seems to me that LLVM sub-register is not for the following hardware architecture. All instructions of a hardware are vector instructions. All registers contains 4 32-bit FP sub-registers. They are called r0.x, r0.y, r0.z, r0.w. Most instructions write more than one elements in this way: mul r0.xyw, r1, r2 add r0.z, r3, r4 sub r5, r0, r1 Notice that the four elements of r0 are written

On Jan 19, 2009, at 9:17 AM, Patrick Boettcher wrote: > Hi list, > > in our LLVM-based-project we are writing a backend for our > processor. The > architecture is a quite straight-forward RISC, but it does not have > hardware interlocks, i.e. data hazards involving memory access must be > resolved by the compiler, either by scheduling unrelated > instructions or >

On Wed, 9 Jun 2004, Vladimir Prus wrote: > > I assume that the two unconditional gotos are just test code, right? If > > not, the second one is dead. > > Yes, in the final form there will be "iflt" instruction before the first goto, > making it conditional. Ah, ok :) > > > The code after "goto" is disturbing. It looks like spill code, but

Dear LLVM guys, I am getting an error with my pass implementation, and I cannot figure it out. Basically, I've implemented part of a register allocation algorithm, but I am having problems to set the passes correctly. For instance, for this program below, the following error message is produced: .c ----------------------| .bc ---------------------------------

Chris Lattner wrote: > On Tue, 8 Jun 2004, Vladimir Prus wrote: > > While adding support for branch instructions in my backend, I run into a > > trouble. The code to handle branches looks like: > > The machine code after instruction selection is: > > > > entry (0x8681458): > > %reg1024 = load <fi#-1> > > %reg1025 = load

Hi list, in our LLVM-based-project we are writing a backend for our processor. The architecture is a quite straight-forward RISC, but it does not have hardware interlocks, i.e. data hazards involving memory access must be resolved by the compiler, either by scheduling unrelated instructions or by inserting NOOPs into the load delay slots: ---- For example, code which looks like that: load

On Thu, 29 Jun 2006, Fernando Magno Quintao Pereira wrote: > I am working in a register allocator for LLVM, and I realized that, > after I perform register allocation, there is many move instructions that > are dead code, and can safely be removed. It is easy for the RA algorithm > to remove these instructions. It seems to me that the only instructions > with dead definitions

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

On Fri, 23 Jun 2006, Fernando Magno Quintao Pereira wrote: > I am getting an error with my pass implementation, and I cannot figure > it out. Basically, I've implemented part of a register allocation > algorithm, but I am having problems to set the passes correctly. For > instance, for this program below, the following error message is > produced: It's hard to say