similar to: InstrEmitter::CreateVirtualRegisters handling of CopyToReg

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

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

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

Hi, Assume I define registers R0...R15 and two register classes RegA and RegB. RegA contains R0 to R7 while RegB contains R0 to R15. Then I check the machine instruction, it seems that in some cases, the %vreg0 belongs to RegB; in other cases %vreg1 belongs to RegA_RegB. Can you tell me how TableGen decides which is which? At first, I guess &verg0 will be assigned by R8 to R15 only so that

On Aug 27, 2010, at 11:53 AMPDT, Yuri wrote: > On 08/27/2010 11:32, Yuri wrote: >> As I understand only one of TCRETURNri64 and RET should be created. >> I have sources of rev.112200. >> >> Here is the stack when TCRETURNri64 instruction is created: >> #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr >> (this=0x30eb000, TID=@0x803a78940,

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

So there's a DAG that looks like this in the debug output: Selecting: t3: ch,glue = CopyToReg t0, Register:i16 %R5, Constant:i16<127> In the instruction selection phase, what pattern would that match? I've constructed this so far: (??? REG16:$dst, i16imm:$src) but the problem is, I can't determine what to use as ???. There is an ISD::CopyToReg enum value, but I don't

On 08/27/2010 11:32, Yuri wrote: > As I understand only one of TCRETURNri64 and RET should be created. > I have sources of rev.112200. > > Here is the stack when TCRETURNri64 instruction is created: > #1 0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr > (this=0x30eb000, TID=@0x803a78940, DL={LineCol = 0, ScopeIdx = 0}, > NoImp=false) at

Hmm, okay. Then what's the problem being reported here? I'm not sure what I'm supposed to do with "LLVM ERROR: Cannot select: t1: i16 = Constant<127>".BTW, the function is: ; ModuleID = 'return.c' source_filename = "return.c" target datalayout = "E-m:e-p:16:16:16-i1:16:16-i8:16:16-i16:16:16-i32:16:16-i64:16:16-S16-n16" target triple =

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

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 :

Well, that's the thing: I thought that was CopyToReg. I don't know what the name of the node is to load one value into a register, so I don't know how to construct such a pattern. On Sat, Nov 4, 2017 at 9:23 PM Craig Topper <craig.topper at gmail.com> wrote: > Do you have a pattern for loading an i16 immediate into a 16-bit register? > > ~Craig > > On Sat, Nov 4,

I am tracking down a tricky bug involving select/CMOV and scheduling. In my test, I have a float select that has to be implemented with a diamond CFG by the scheduler. The high level ScheduleDAGSDNodes::EmitSchedule does this: for (unsigned i = 0, e = Sequence.size(); i != e; i++) { [...] Emitter.EmitNode(SU->getNode(), SU->OrigNode != SU, SU->isCloned,

Hi, I'm trying to understand how virtual regs are assigned to operands in IR instructions. I looked into SelectionDAG but could not figure out where the assignment happens. How and where does this conversion happen? Furthermore, I want to build a map between variable and the virtual register (x corresponds to vreg11 in below code). I've been stuck here for a while. Any help is greatly

Hi, On SystemZ there are a set of "access registers" that can be copied in and out of 32-bit GPRs with special instructions. These instructions can only perform the copy using low 32-bit parts of the 64-bit GPRs. As reported and discussed at https://bugs.llvm.org/show_bug.cgi?id=44254, this is currently broken due to the fact that the default register class for 32-bit integers is

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

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

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

Hi Hal, Thanks for the guidance. I hope you don’t mind that I’m adding LLVMDev to this e-mail thread, as it seems as though it may be of general interest. I agree that duplicating the FP opcodes should be our goal. I just wasn’t sure that was entirely possible. I’ll try adding implicit defs in the way you’ve suggested, but I’m concerned that there may be code that relies on the TII for that

Can you elaborate on the fix you are thinking of? I'm not sure what you're thinking should change. On Tue, Nov 19, 2019 at 3:51 PM Quentin Colombet <qcolombet at apple.com> wrote: > It sounds to me that we should fix SDISel to accept both physical and > virtual definitions on variadic instructions. Though I wouldn’t bother > adding the support for implicit virtual