similar to: [LLVMdev] BranchInst problem

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 <fi#-2> > setcc %reg1024, %reg1025 >

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,

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

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

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

Folks, I'm running into something which looks like a bug in linearscan allocator. Of course I can't be 100% sure it's not some unobvious mistake on my part, so I'd like to hear your opinion. First, I attach two files -- LLVM asm and the asm for my target. The problem with assembler is: on line 171 it uses register gr2, which is copied from gr6 above, on line 161. The only

Hello, this is another "allocator crashes hard when I pass wrong data to it" issue. Due to a bug, my machine code looked like this: # Machine code for list_sequence(): <fi #-2> is 4 bytes fixed at location [SP-24] <fi #-1> is 4 bytes fixed at location [SP-20] entry (0x8060970, LLVM BB @0x805da88): %reg1024 = load <fi#-1> %reg1025 = load

Chris Lattner wrote: > > > I'm not sure either. Can you send the code before and after register > > > allocation? > > > > Attached. > > Okay, yeah the spill code looks right. The local allocator can't keep > virtual registers in physical registers across basic blocks. As such, the > vregs are spilled at the end of the entry block and then

VLIW (Very Long Instruction Word) is a long instruction format (called "group" hereafter) contains several instructions. These instructions are not dependent on each other and could be issued in a single cycle. At this moment there is no correspondent class for VLIW. MachineInstr object can only represent one instruction. Usually the number of instructions in a group is fixed. The

hi, i know it took a while, but here is a patch that adds a list of source values to machine instructions. i modified the DAGISelEmiter to automatically catch regular loads/stores. custom instructions and loads/stores rewritten by the lowering pass are not automatically captured. during the instruction selection a source value operand is added to the DAG for patterns matching a load/store.

On Mar 27, 2007, at 3:25 PM, Evan Cheng wrote: > > On Mar 25, 2007, at 7:12 AM, Christopher Lamb wrote: > >> While beginning to add vector registers to a back end I came >> across the following problem: as soon as I define two sets of >> registers that have a many-to-one mapping the live interval pass >> appears to double-kill the mapped-onto register. I

2005/12/13, Chris Lattner <sabre at nondot.org>: > On Tue, 13 Dec 2005, Tzu-Chien Chiu wrote: > > > In my ISA, some registers are write-only. These registers serve as > > output ports, writing to these registers will output the values to an > > external device. They cannot be read. So their live intervals should > > not be joined with any other registers. >

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 Apr 3, 2007, at 3:45 PM, Christopher Lamb wrote: > >> Can you dump out the machine basic block? It should have an >> implicit use of V4R0 at first ORI but it should not be marked kill. >> If it is marked kill, then you need to walk LiveVariables.cpp to >> find out why. > > Here is the beginning of the BB dump. > > entry (0x8503c80, LLVM BB @0x8501af0,

hi, Florian Brandner wrote: > Dan Gohman wrote: >> On Wed, May 23, 2007 at 12:23:38AM -0700, Chris Lattner wrote: >>> Right. The original Value*'s are preserved in the DAG, but dropped when >>> MachineInstrs are created. We could add a machineoperand to capture this >>> Value* if desired. >> Another benefit of keeping the original Value*'s

While beginning to add vector registers to a back end I came across the following problem: as soon as I define two sets of registers that have a many-to-one mapping the live interval pass appears to double- kill the mapped-onto register. I have the following excerpts from my RegisterInfo.td. def V4R0 : R4v<0 , "V4R0 ", []>, DwarfRegNum<0>; def R0 : Rg<0 ,

On Tue, 13 Dec 2005, Tzu-Chien Chiu wrote: > In my ISA, some registers are write-only. These registers serve as > output ports, writing to these registers will output the values to an > external device. They cannot be read. So their live intervals should > not be joined with any other registers. Ok. Since they are not really registers in the sense that LLVM is used to, I

I'm using the fixed argument in arima. Shouldn't ar4, ar5, and ar6 display as zero in the output? Call: arima(x = window(log(hhprice), start = c(1990, 1), end = c(2003, 3)), order = c(7, 1, 0), xreg = window(ts.union(exa1 = lag(exa, -1), exa12 = lag(exa, -12), exb1 = lag(exb, -1), exc1 = lag(exc, -1), exc12 = lag(exc, -12)), start = c(1990, 1), end = c(2003, 3)),

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