similar to: Removing the register block in MIR

Hi Ryan, > On Aug 24, 2015, at 6:49 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Quentin, > > I apologize for the spamming here but in getVR (where VReg is assigned an RC), it calls: > > const TargetRegisterClass *RC = TLI->getRegClassFor(Op.getSimpleValueType()); > VReg = MRI->createVirtualRegister(RC); > > My question is why is it using the

Quentin, This is the issue. Somewhere prior to the constrainRegClass, it's assigning the GPRBase sub class of GPR to the MOV instruction, so it can't constrain it to Base and hence has to add the COPY. Now I just need to find out why it is ignoring the TableGen defined GPRBase for the MOV MI in favor of it's sub class GPR. Thanks. On Mon, Aug 24, 2015 at 8:34 PM, Ryan Taylor

> On Aug 24, 2015, at 4:46 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Here is the snippet that matters: > > void > InstrEmitter::AddRegisterOperand(MachineInstrBuilder &MIB, > SDValue Op, > unsigned IIOpNum, > const MCInstrDesc *II, >

I have not tried 3.5, it's a significant amount of work to port from one version to the next though, I did not personally do the 3.4 to 3.6 porting. I agree though, it was very strange that it suddenly just changed behavior. It looks like to me that InstrEmitter.cpp:getVR is the one assigning the virtual register no? Though this code in CreateVirtualRegisters: const TargetRegisterClass *RC

1. MOV16Copy_IMM_REG is the instruction matched, sorry. AD is the multiclass. The IMM in my case is a global. So you can see that GPRBaseRegs, GPRBaseRegs sets the registerclass for both the src and dst operands, in this case (MOV16Copy_IMM_REG) it's the dst. 2. Yes I agree, it most likely would. Honestly, this comes across like a bug, or unintended feature. It's adding an extra COPY to

AddRegisterOperand calls getVR and yes, I think an IMPLICIT_DEF is being generated. On Tue, Aug 25, 2015 at 2:40 PM, Quentin Colombet <qcolombet at apple.com> wrote: > > On Aug 25, 2015, at 11:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I have not tried 3.5, it's a significant amount of work to port from one > version to the next though, I did not

Here is the instruction in question: multiclass AD<string asmstr, SDPatternOperator OpNode, RegisterClass srcAReg, RegisterClass dstReg, ValueType srcAType, ValueType dstType, Operand ImmOd, ImmLeaf imm_type> { def REG_REG : SetADInOut<asmstr, srcAReg, dstReg, [(set dstReg:$dstD, (OpNode srcAReg:$srcA))]>; def IMM_REG :

BB#0: derived from LLVM BB %entry %vreg0<def> = MOV16Copy_IMM_REG <ga:@a+1>[TF=1]; GPRRegs:%vreg0 %vreg1<def> = COPY %vreg0; PTRRegs:%vreg1 GPRRegs:%vreg0 Send_iii %NULLR0, %vreg1<kill>, 1, 1, 1, 1, 0; PTRRegs:%vreg1 RetRA This is what I get. This is what I'd like to get: BB#0: derived from LLVM BB %entry %vreg0<def> = MOV16Copy_IMM_REG

> On Aug 24, 2015, at 1:30 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm trying to do something like this: > > // Dst = NewVReg's reg class > // *II = MCInstrDesc > // IIOpNum = II Operand Num > > if (TRI->getCommonSubClass(DstRC, TRI->getRegClass(II->OpInfo[IIOpNum].RegClass)) == DstRC) > MRI->setRegClass(VReg, DstRC); >

I try to define a register class def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] to simulate even/odd pair of GPR32 register. Actually, I just use GPR64 as a temporary register. My CPU just support i32 Integer type directly. I use FDR to save f64. def FDR : RegisterClass<"mytarget", [f64], 64,[FD0, FD1, ....] When I move f64 to even/odd pair register, I

Dear Evan Chang: I register incorrect Register class for MVT::f64. I have fixed it. Thanks your advice. "-view-legalize-dags" is very good option. But I don't know why my LLC do not know " -view-legalize-type-dags" option. By the way, I use llvm 2.5 merged from llvm2.4. Best Regards, Ren Kun --- 09年3月31日，周二, Evan Cheng <echeng at apple.com> 写道： 发件人: Evan Cheng

On Feb 19, 2009, at 8:26 PM, 任坤 wrote: > hi, Dear Evan Cheng: > > My cpu is i32 embeded CPU. I define pseudo register pair registers. > > In mytargetRegisterInfo.td: > def T0: RegisterWithSubRegs<"t0",[R0,R1]>; > ... > def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] > > In mytargetISelLowering.cpp: > I define i1, i8 ,

> On Aug 22, 2015, at 9:10 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > One last question regarding this please. > > Why aren't we simply changing the register class in AddRegisterOperand instead of building a new COPY? I admit I haven't thought this out but for my test cases so far this works just fine and reduces the number of ASM mov instructions that are

hi, Dear Evan Cheng: My cpu is i32 embeded CPU. I define pseudo register pair registers. In mytargetRegisterInfo.td: def T0: RegisterWithSubRegs<"t0",[R0,R1]>; ... def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] In mytargetISelLowering.cpp: I define i1, i8 , i16 and i32 are legal. 1. I still have problem. I save my function return double  value in

Hi, My name is Puyan and I've been exploring ways to improve the state of instruction level diffing using llvm and MIR. Below is a proposal for a new llvm tool meant to address issues encountered when diffing at the machine level. I'm eager to hear the community's feedback. Thanks PL mir-canon: A new tool for canonicalizing MIR for cleaner diffing. Problem Statement and

Dan Gohman <gohman at apple.com> writes: > On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: >> Am I misusing register classes, or is this simply functionality that >> has not been written yet? The existing backends seem to have only one >> register class per machine value type. > > The x86 backend has an example of a partial solution. The GR32 >

On Mar 16, 2009, at 11:31 AM, Jakob Stoklund Olesen wrote: > Dan Gohman <gohman at apple.com> writes: > >> On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: >>> Am I misusing register classes, or is this simply functionality that >>> has not been written yet? The existing backends seem to have only >>> one >>> register class per

Hi, I am writing a backend for the Blackfin processor from Analog Devices. I just started so I still have a lot to learn about the code generator. So far, I can compile test/CodeGen/Generic/BasicInstrs.ll correctly, but that is about it. The Blackfin 32-bit registers divide naturally into several classes. I have modelled these register classes without knowing anything about what the code

On Mar 15, 2009, at 2:02 PM, Jakob Stoklund Olesen wrote: > Hi, > > I am writing a backend for the Blackfin processor from Analog > Devices. I > just started so I still have a lot to learn about the code > generator. So > far, I can compile test/CodeGen/Generic/BasicInstrs.ll correctly, but > that is about it. > > The Blackfin 32-bit registers divide naturally

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>