similar to: [LLVMdev] Problem with isMoveInstr

On Thu, 2004-07-01 at 09:26, Vladimir Prus wrote: > I've tried to implement the isMoveInstr method from TargetInstrInfo class, and > the register allocator immediately started to crash, in: > > #4 0x40e88787 in llvm::LiveIntervals::joinIntervals (this=0x80630b0) > at ../lib/CodeGen/LiveIntervals.cpp:493 > 493 assert(r2iA != r2iMap_.end()); >

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,

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

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

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

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

Vladimir Prus wrote: > On my target, the multiplication can involve all general purpose registers, > but there's are still some restrictions: the first and the second operand > as well as the result must be in different registers, and neither register > can be gr7. How can I enforce this restriction on the register allocator? And the other side of the question is now to inform

On my target, the multiplication can involve all general purpose registers, but there's are still some restrictions: the first and the second operand as well as the result must be in different registers, and neither register can be gr7. How can I enforce this restriction on the register allocator? - Volodya

Chris Lattner wrote: > On Tue, 22 Jun 2004, Vladimir Prus wrote: > > 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 predecessor of this basic > > block is jump on line 90. The problem is that gr6 is not initialized in > >

On Wed, 23 Jun 2004, Vladimir Prus wrote: > Hmm.. this is what I have in td file already: > > let isTerminator = 1 in > def GOTO : Unknown<"goto">; > def IFEQ : Unknown<"if =0 goto">; > def IFNEQ : Unknown<"if <>0 goto">; > ..... > > Should this work? Nope, but try this: let isTerminator = 1 in {

I am considering adding a new target independent codegen-only COPY instruction to our MachineInstr representation. It would be used to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer. The COPY instruction handles subreg operations with less

I have just added a retflag to the ARM backend. I thought that using BRIND directly was to blame for a dummy move. But I the move wasn't removed. When compiling --------------------------------------- int %g() { entry: call void %f( ) ret int 42 } declare void %f() -------------------------------------- The ARM backend produces ------------------------------------------- g:

On 1/18/07, Scott Michel <scottm at rushg.aero.org> wrote: > Is there any way I can detect when this occurs, or is there code > where this detection takes place in the target to which I can > refer? have you implemented InstInfo::isMoveInstr to recognize those? The register allocator uses that to find copies it can remove. Andrew

Evan Cheng wrote: > On Apr 16, 2009, at 3:17 PM, Greg McGary wrote: > >> Is there some optimizer knob I'm not turning properly? In more complex >> cases, GCC does poorly with two-address operand choices and so bloats >> the code with unnecessary register moves. I have high hopes LLVM >> can do better, so this result for a simple case is bothersome. >>

Hi again, Now, after I fixed the graph coloring regalloc bug that was triggered by the ARM target, I continue testing and found another bug, this time on the XCore target. First I thought that it is again specific to my register allocator, but it seems to be trigerred also by LLVM's linearscan register allocator. I don't know if the XCore target is stable enough in LLVM, or may be I

On Tue, 22 Jun 2004, Vladimir Prus wrote: > 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 predecessor of this basic block is jump on line > 90. The problem is that gr6 is not initialized in the interval from the > function entry till the

On Mon, 9 Oct 2006, Roman Levenstein wrote: > I'm now ready to implement the FP support for my embedded target. cool. > My target supports only f64 at the moment. > Question: How can I tell LLVM that float is the same as double on my > target? May be by assigning the same register class to both MVT::f32 > and MVT::f64? Just don't assign a register class for the f32 type.

Roman Levenstein wrote: > Hi again, > > Now, after I fixed the graph coloring regalloc bug that was triggered > by the ARM target, I continue testing and found another bug, this time > on the XCore target. First I thought that it is again specific to my > register allocator, but it seems to be trigerred also by LLVM's > linearscan register allocator. > > I don't

2009/6/12 Bob Wilson <bob.wilson at apple.com> > Thanks, this should be useful. What problem did you have with svn > revisions after 70786? /tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/xgcc -B/tmp/llvm-project.p28262/obj/llvm-gcc-4.2/./gcc/ -B/tmp/llvm-73246/llvm-project/x86_64-unknown-linux-gnu/arm-none-linux-gnueabi/llvm-gcc-4.2/arm-none-linux-gnueabi/bin/