similar to: [LLVMdev] Bug in LiveIntervals? Please Examine

On Jul 17, 2009, at 7:57 AM, David Greene wrote: > In LiveIntervals::processImplicitDefs() we have this: > > for (MachineRegisterInfo::use_iterator UI = mri_->use_begin(Reg), > UE = mri_->use_end(); UI != UE; ) { > MachineOperand &RMO = UI.getOperand(); > MachineInstr *RMI = &*UI; > ++UI; > MachineBasicBlock *RMBB

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh wait, vreg1 is indeed used. > Yeah, having a dead flag here sounds wrong. I mean on the instruction itself. On the bundle, that’s debatable. That would fit the semantic “if no side effect you can kill it” (here there is side effect, we define other vregs). > >> On

Hi Quentin and llvm-dev, I've got a regalloc-related question that you might have an opinion or answer about. In our out-of-tree target we've been doing some bundling before register allocation for quite some time now, and last night a new problem popped up. What the fix should be depends on if this bundle is legal or not: BUNDLE %vreg39<imp-def,dead> *

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

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

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

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 :

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

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

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

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 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, I'm playing with some experimental register allocators for LLVM. One of them needs to build a so-called register class tree for representing the aliasing information among register classes. This tree is not function or module specific. It is actually target specific, because it depends only on the register classes defined for a machine that is used as a target of the current compilation.

Hi people, the LinearScan register allocator tries to use same register for both live intervals, if the new interval is defined by a register copy whose destination reg is compatible with the source register. This is ok. However, this "check for compatibility" is wrongly done IMHO. Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but regclass2 defines only

I've been playing around with spillers and found that the SimpleSpiller fails badly on a particular code. The problem arises because SimpleSpiller does the test VRM.isAssignedReg(virtReg) which is implemented as: 00183 bool isAssignedReg(unsigned virtReg) const { 00184 if (getStackSlot(virtReg) == NO_STACK_SLOT && 00185 getReMatId(virtReg) == NO_STACK_SLOT)

On Wednesday 11 July 2007 15:07, Christopher Lamb wrote: > Could it be possible for there to be a harness type interface that > would allow coalescers that support both modes to be hooked into the > pass registration, and those that depend on the allocator not be > registered as passes? I have a patch for this kind of thing attached. Please take a look and let me know if it looks

On Jul 11, 2007, at 11:39 AM, David Greene wrote: > On Wednesday 11 July 2007 12:41, Tanya M. Lattner wrote: > >> I think the coalescer should be flexible enough to be run >> independent of >> the register allocator. For example, you may want to expose the >> copies >> induced by transforming out of SSA to the scheduler. If the >> scheduler is

Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn'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

Hi all, we're suffering heavily from the "connection reset by peer" problem when running Rsync on WinNT. Great was our relief when seeing Randy's message in http://www.mail-archive.com/rsync@lists.samba.org/msg01918.html I immediately installed the full Cygwin to recompile Rsync, but since I'm far from a C guru, I'm a bit puzzled with the last 2 lines in Randy's