similar to: [LLVMdev] LiveVariables not updated in MachineBasicBlock::SplitCriticalEdge?

On May 2, 2011, at 3:51 PM, Akira Hatanaka wrote: > - vreg81's VarInfo: > Alive in blocks: 5, 6, 7, 8, 10, 12, 13, 19, > Killed by: > #0: J <BB#17> > > > As you can see, VarInfo vreg81 is killed by the unconditional jump instruction of BB#20 when it should be killed by the newly created conditional branch in BB#14 (BEQ). Is this a bug in

Does updateTerminator() need to be rewritten in order to implement the changes you suggested (call LV->replaceKillInstruction)? Or can it be taken care of just by adding code to the files in Target/Mips? Also, is the generated code still correct if -disable-phi-elim-edge-splitting is added to the command line options? On Mon, May 2, 2011 at 5:00 PM, Jakob Stoklund Olesen <stoklund at

Hi, I am trying to do a backend to a very simple microcontroller. I have some questions. 1) I have instruction which do "r1 <- r1 op r2", from what I have ssen I must declare them like: let isTwoAddress = 1 in def ADD : FopRR< 0b01010, (outs CPURegs:$sX), (ins CPURegs:$isX, CPURegs:$sY), "ADD $sX, $sY"), [(set

On Apr 27, 2008, at 7:37 AM, Cédric Venet wrote: > Hi, > > I am trying to do a backend to a very simple microcontroller. I have > some > questions. Ok. > 1) I have instruction which do "r1 <- r1 op r2", from what I have > ssen I > must declare them like: > > let isTwoAddress = 1 in > def ADD : FopRR< 0b01010, > (outs

Dear all, The architecture I am working with supports moving values directly from one register to another, or moving an immediate straight to a register, and I cannot figure out how to do this in LLVM. I originally tried matching something like [(set RegisterClass:$dest, RegisterClass:$src)] in my TargetInstrInfo.td: def MOVrr : MyInstrClass<(outs CPURegs:$dest), (ins CPURegs:$src),

Hello David, Thanks for your example. Is that means that DAG pattern is consist of LLVM IR instruction?? I met an example [(set CPURegs:$dst, (OpNode CPURegs:$b, CPURegs:$c))] of MipsInstrInfo.td, but I can't find correspond LLVM IR instruction of "set" in "LLVM Language Reference Manual". Is that correspond to $dst = op $b, $c?? Would you mind to tell me whether there is

I have a target backend which is currently causing live interval analysis to throw 'Interval not live at use' errors for many of my benchmarks. I imagine that this is caused by missing information for my target (probably in the instructioninfo tablegen?), but I am having difficulties in both debugging and fixing this problem, and would appreciate any advice or help anyone can give.

Do you want to replace lui $2, %hi(g1) addiu $2, $2, %lo(g1) with this? la $2, g1 If that is the case, you can add this pattern. def op_la : Operand<i32>; def LA : FI<0x09, (outs CPURegs:$dst), (ins op_la:$addr0, op_la:$addr1), "la $dst, $addr0", [(set CPURegs:$dst, (add (MipsHi tglobaladdr:$addr0), (MipsLo tglobaladdr:$addr1)))], IIAlu>;

On Mar 6, 2012, at 5:05 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I am having trouble trying to enable post RA scheduler for the Mips backend. > > This is the bit code of the function I am compiling: > > (gdb) p MF.Fn->dump() > > define void @PointToHPoint(%struct.HPointStruct* noalias sret > %agg.result, %struct.ObjPointStruct* byval %P) nounwind {

Hi everyone I'm hitting an assertion in PHIElimination.cpp:375. "Terminator instructions cannot use virtual registers unless" "they are the first terminator in a block!" I was looking at the code around that location a bit and have not found a reason why this assertion has to hold, except for a comment: // In our final twist, we have to decide which instruction

I am having trouble trying to enable post RA scheduler for the Mips backend. This is the bit code of the function I am compiling: (gdb) p MF.Fn->dump() define void @PointToHPoint(%struct.HPointStruct* noalias sret %agg.result, %struct.ObjPointStruct* byval %P) nounwind { entry: %res = alloca %struct.HPointStruct, align 8 %x2 = bitcast %struct.ObjPointStruct* %P to double* %0 = load

I reiterate. You should fix the simulator. It is broken. The compiler is not. Fix what's broken. -Jim On Oct 7, 2011, at 1:11 PM, Gang-Ryung Uh wrote: > Hi, > > I noticed one class in MipsInstrFormats.td:L46 -> Class MipsPseudo. I wonder whether I can use this. If does, I wonder what would be the right way to use. Thanks, > > > > On Thu, Oct 6, 2011 at

Hi, I noticed one class in MipsInstrFormats.td:L46 -> Class MipsPseudo. I wonder whether I can use this. If does, I wonder what would be the right way to use. Thanks, On Thu, Oct 6, 2011 at 11:29 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Do you want to replace > > lui $2, %hi(g1) > addiu $2, $2, %lo(g1) > > with this? > la $2, g1 > > If that

On Mar 7, 2012, at 11:34 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I filed a bug report (Bug 12205). > Please take a look when you have time. > > Per your suggestion, I also attached a patch which attaches to load or > store nodes a machinepointerinfo that points to a stack frame object > when it can infer they are actually reading from or writing to the >

Hi all, I'm trying to create a new backend for a processor, and I start with modifying the existing backends like MIPS and Microblaze. I have a problem when I try to add a register class in the Target's register description, it looks like this: def IGPRegs : RegisterClass<"MBlaze", [v8i16], 128, [PR0, PR1, PR2, PR3]>; // PR0 - PR3 are registers defined before I want to

I don't think I ever said that the MIPS target is broken. I am simply trying to branch out one additional llc target for SimpleScalar PISA architecture. On Fri, Oct 7, 2011 at 2:41 PM, Jim Grosbach <grosbach at apple.com> wrote: > I reiterate. You should fix the simulator. It is broken. The compiler is > not. Fix what's broken. > > -Jim > > On Oct 7, 2011, at 1:11

I filed a bug report (Bug 12205). Please take a look when you have time. Per your suggestion, I also attached a patch which attaches to load or store nodes a machinepointerinfo that points to a stack frame object when it can infer they are actually reading from or writing to the stack. The test that was failing passes if I apply this patch, but I doubt this is the right approach, because this

Thank you for your suggestions. I implemented the first approach (provided the byval argument and offset to MachinePointerInfo) and it seems to have fixed the instruction ordering problem. It was a lot simpler than initially expected. In this particular case, is the user responsible for providing alias information to MachinePointerInfo to guarantee instructions are emitted in the correct order?

On Jan 24, 2012, at 1:46 AM, Reed Kotler wrote: > Mips16 is a mode of the Mips32 (or Mips64) processor. For the most part, > it is a compressed form of the MIPS32 instruction set, though not all > instructions are supported. Most of the same opcodes and formats are > present though sometimes with some restriction. (The micro mips > architecture is a true 16 bit compressed form

I believe that table gen builds MipsGenAsmMatcher.inc which has the Match routines like MatchRegisterName(). In building MipsGenAsmMatcher.inc I am hitting the following issue (actually several, but they may be related). It may have something to do with the $$ escape sequence: /home/jcarter/workarea/llvm/lib/Target/Mips/Mips64InstrInfo.td:173:1: error: error: unable to find operand: