search for: addregisteroperand

...))->getReg();            if (TargetRegisterInfo::isVirtualRegister(Reg)) { -            const TargetRegisterClass *RegRC = MRI->getRegClass(Reg); -            if (RegRC == RC) { +            // Allow constraining the virtual register's class within reason, +            // just like what AddRegisterOperand will allow. +            const TargetRegisterClass *ConstrainedRC +              = MRI->constrainRegClass(Reg, RC, MinRCSize); +            if (ConstrainedRC) {                VRBase = Reg;                MIB.addReg(VRBase, RegState::Define);                break;              }           ...

...2015 at 3:56 PM, Quentin Colombet <qcolombet at apple.com> wrote: > Oh, could you paste the MIs you get right after ISel (the whole def use > chain of the interesting vregs)? > > Q. > > On Aug 25, 2015, at 12:00 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > 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...

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

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

> 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, > DenseMap<SDValue, unsigned> &VRBaseMap, >...

...lombet at apple.com>> wrote: > >> On Aug 22, 2015, at 9:10 AM, Ryan Taylor <ryta1203 at gmail.com <mailto: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 being produced. >> >> For example, instead of BuildMI(..., TII->get(TargetOpcode::COPY), NewVReg).addReg(V...

...t; > On Mon, Aug 24, 2015 at 8:08 PM, Quentin Colombet <qcolombet at apple.com> > wrote: > >> >> 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, >> DenseMap<SDValue, unsigned> &VRBaseMap...

...gt; On Tue, Aug 25, 2015 at 12:29 PM, Quentin Colombet <qcolombet at apple.com> >> wrote: >> >>> >>> On Aug 25, 2015, at 9:23 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >>> >>> Quentin, >>> >>> 1. I'm looking at AddRegisterOperand in InstrEmitter.cpp >>> 2. I'm not sure what you mean. In InstrInfo.td the MI is using GPRBase >>> reg class for both src and dst (it's a mov MI). I need a class just for GPR >>> also, since some operands can only map to GPR and not GPRBase, so I can't >&...

...'t just pick GPRRegs all the time). Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a superset reg class that actually matched the correct reg usage (which it sort of does in AddRegisterOperand when it adds the extra COPY.... not sure why it does this instead of just checking the original MI and seeing if the reg class needed is in the list and then just changing the vreg reg class for the original MI, that seems like a better solution?) It's like it's actually picking some reg cl...

...bet at apple.com >>>> > wrote: >>>> >>>>> >>>>> On Aug 25, 2015, at 9:23 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >>>>> >>>>> Quentin, >>>>> >>>>> 1. I'm looking at AddRegisterOperand in InstrEmitter.cpp >>>>> 2. I'm not sure what you mean. In InstrInfo.td the MI is using >>>>> GPRBase reg class for both src and dst (it's a mov MI). I need a class just >>>>> for GPR also, since some operands can only map to GPR and not GPRBa...

...9 PM, Quentin Colombet <qcolombet at apple.com> >>> wrote: >>> >>>> >>>> On Aug 25, 2015, at 9:23 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >>>> >>>> Quentin, >>>> >>>> 1. I'm looking at AddRegisterOperand in InstrEmitter.cpp >>>> 2. I'm not sure what you mean. In InstrInfo.td the MI is using >>>> GPRBase reg class for both src and dst (it's a mov MI). I need a class just >>>> for GPR also, since some operands can only map to GPR and not GPRBase, so I &gt...

> 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 being produced. > > For example, instead of BuildMI(..., TII->get(TargetOpcode::COPY), NewVReg).addReg(VReg), us...

Jakob Stoklund Olesen <jolesen at apple.com> writes: > These sub-registers are special, they are only mentioned here: > > let CompositeIndices = [(sub_ss), (sub_sd)] in { > def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; > def XMM1: Register<"xmm1">, DwarfRegNum<[18, 22, 22]>; > ... I'm confused. Below you

All, I've been trying to simplify the way LLVM models sub-register relationships a bit, and the X86 sub_ss and sub_sd sub-register indices are getting in the way. I want to get rid of them. These sub-registers are special, they are only mentioned here: let CompositeIndices = [(sub_ss), (sub_sd)] in { def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; def

...SUBREG and COPY_TO_REGCLASS are emitted as COPY instructions by InstrEmitter. One as a sub-register copy, one as a full register copy. Both are handled by the register coalescer. It would actually be possible to have EmitCopyToRegClassNode() try to call MRI->constrainRegClass() first, just like AddRegisterOperand() does. That could avoid the copy in some cases, and you would simply get a VR128 register as the second VMOVSDrr operand. I am not proposing we do that for now. Let the register coalescer deal with that. > What happens if the result of the above pattern using COPY_TO_REGCLASS > is spilled?...

It seems the problem arises from using multiple reg classes for one MI in the td file, I guess. I'm not sure it takes first available, if I swap the reg classes in the list it does not change and if I replace the GPR reg class with something different than it picks the base reg class fine, potentially it is using the reg class with most available? idk. I just need to create MIs for every

...Registers(llvm::SDNode*, llvm::MachineInstr*, llvm::TargetInstrDesc const&, bool, bool, llvm::DenseMap<llvm::SDValue, unsigned int, llvm::DenseMapInfo<llvm::SDValue>, llvm::DenseMapInfo<unsigned int> >&)in libLLVMSelectionDAG.a(InstrEmitter.cpp.o) llvm::InstrEmitter::AddRegisterOperand(llvm::MachineInstr*, llvm::SDValue, unsigned int, llvm::TargetInstrDesc const*, llvm::DenseMap<llvm::SDValue, unsigned int, llvm::DenseMapInfo<llvm::SDValue>, llvm::DenseMapInfo<unsigned int> >&, bool, bool, bool)in libLLVMSelectionDAG.a(InstrEmitter.cpp.o) llvm::InstrEm...