search for: basereg

...e instruction should be a tLEApcrel or t2LEApcrelJT; we want // to delete it as well. MachineInstr *LeaMI = PrevI; if ((LeaMI->getOpcode() != ARM::tLEApcrelJT && LeaMI->getOpcode() != ARM::t2LEApcrelJT) || LeaMI->getOperand(0).getReg() != BaseReg) OptOk = false; if (!OptOk) continue; I am trying to figure out why the restriction of LeaMI->getOperand(0).getReg() != BaseReg is there. It seems this is overly restrictive. For example, here is a case where it succeeds: 8944B BB#53: derived from LLVM BB %1...

...; // to delete it as well.**** > > *MachineInstr* *LeaMI = PrevI;**** > > *if* ((LeaMI->getOpcode() != *ARM*::tLEApcrelJT &&**** > > LeaMI->getOpcode() != *ARM*::t2LEApcrelJT) ||**** > > LeaMI->getOperand(0).getReg() != BaseReg)**** > > OptOk = *false*;**** > > ** ** > > *if* (!OptOk)**** > > *continue*;**** > > ** ** > > I am trying to figure out why the restriction of > LeaMI->getOperand(0).getReg() != BaseReg is there. It seems this is overly > restrict...

...T; we want > > // to delete it as well. > > MachineInstr *LeaMI = PrevI; > > if ((LeaMI->getOpcode() != ARM::tLEApcrelJT && > > LeaMI->getOpcode() != ARM::t2LEApcrelJT) || > > LeaMI->getOperand(0).getReg() != BaseReg) > > OptOk = false; > > > > if (!OptOk) > > continue; > > > > I am trying to figure out why the restriction of LeaMI->getOperand(0).getReg() != BaseReg is there. It seems this is overly restrictive. For example, here is a case w...

Hello, This patch aims to improve compile time performance by increasing the SCEV vector size in LoopStrengthReduce. It is observed that the BaseRegs vector size is 4 in most cases, and elements are frequently copied when it is initialized as SmallVector<const SCEV *, 2> BaseRegs. Our benchmark results show that the compilation time performance improved by ~0.5%. Patch by Wan Xiaofei. Thanks Sriram -------------- next part -------------...

...er registers without considering the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs) 2. Cost comparison solely favors the number register without considering other Impacts. For the case one, NarrowSearchSpaceByPickingWinnerRegs filters by most occurred registers. ld(basereg, immediate) is a target preferred addressing mode. However, it may be deleted because basereg is very likely not to be the most occurred register because the less opportunity in a combination. For the case two, by observing the cost comparison equation bool Cost::operator<(const Cost &a...

.../lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp index 7952607..12a30cf 100644 --- a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp +++ b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp @@ -402,6 +402,56 @@ void X86MCCodeEmitter::EmitMemModRMByte(const MCInst &MI, unsigned Op, unsigned BaseRegNo = BaseReg ? GetX86RegNum(Base) : -1U; + // 16-bit addressing forms of the ModR/M byte have a different encoding for + // the R/M field and are far more limited in which registers can be used. + if (Is16BitMemOperand(MI, Op)) { + if (BaseReg) { + // See Table 2-1 "16-Bit Addressi...

...tgReturn return from the Haskell world into C world again safely. They are defined in rts/StgCRun.c and the comment from the top of the file might be more useful here than my writing about it: * STG-to-C glue. * * To run an STG function from C land, call * * rv = StgRun(f,BaseReg); * * where "f" is the STG function to call, and BaseReg is the address of the * RegTable for this run (we might have separate RegTables if we're running * multiple threads on an SMP machine). * * In the end, "f" must JMP to StgReturn (defined below), passing the...

...(directStore (dstType (OpNode srcAReg:$srcA)), addr16:$dstD)]>; def MEM_MEM : SetADIn<asmstr, memhx, memhx, [(directStore (dstType (OpNode (srcAType (load addr16:$srcA)))), addr16:$dstD)]>; } defm MOV16Copy_ : AD<"mov16", null_frag, GPRBaseRegs, GPRBaseRegs, i16, i16, simm16, immSExt16x>; On Tue, Aug 25, 2015 at 1:02 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Quentin, > > 1. I'll take a look, it's also picking the reg class by the > SimpleValueType and then getting the common subclass. Choosing to c...

Hi Andy, Actually, if we just add hooks that preserves the existing behavior, It is not difficult. For example, For case one, we can define one function like virtual const SCEV* getTargetPreferredWinnerReg(const SCEV*& ScaledReg, SmallVector<const SCEV *, 4>& BaseRegs, GlobalValue*& BaseGV) const; In NarrowSearchSpaceByPickingWinnerRegs, we can preserves the winner reg from target and winner reg from the original algorithm if this function returns NULL, it is just like before For case two, we can define a general cost from TTI function, like...

On 29 June 2012 17:46, Karel Gardas <karel.gardas at centrum.cz> wrote: > Yes and no. Shortly: original GHC/ARM/LLVM port was done by Stephen on > ARMv5/Qemu IIRC. I've later added whole VFP support and ARMv7 support. The > code in GHC is properly #ifdefed, so if there is no VFP available on pre > ARMv6, then it's not used. ie. GHC STG floating points regs are then >

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 move from a GPR to a Base when a Base is...

...CCodeEmitter.cpp > index 7952607..12a30cf 100644 > --- a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > +++ b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > @@ -402,6 +402,56 @@ void X86MCCodeEmitter::EmitMemModRMByte(const MCInst > &MI, unsigned Op, > > unsigned BaseRegNo = BaseReg ? GetX86RegNum(Base) : -1U; > > + // 16-bit addressing forms of the ModR/M byte have a different encoding > for > + // the R/M field and are far more limited in which registers can be > used. > + if (Is16BitMemOperand(MI, Op)) { > + if (BaseReg) { > +...

...t 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 = TRI->getAllocatableClass(TII->getRegClass(II, i, TRI, *MF)); That returns GPRBaseRegs for RC, but it then decides to constrain it based on type: if (i < NumResults && TLI->isTypeLegal(Node->getSimpleValueType(i))) { const TargetRegisterClass *VTRC = TLI->getRegClassFor(Node->getSimpleValueType(i)); errs()<<"CVR VTRC: "&lt...

...dering > the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs) > 2. Cost comparison solely favors the number register without considering other > Impacts. > > For the case one, > NarrowSearchSpaceByPickingWinnerRegs filters by most occurred registers. > ld(basereg, immediate) is a target preferred addressing mode. However, it may > be deleted because basereg is very likely not to be the most occurred register > because the less opportunity in a combination. > > For the case two, by observing the cost comparison equation > bool Cost::operator...

...getVR only create the virtual register for implicit defs. Which > is not your case, right? > > > Though this code in CreateVirtualRegisters: > > const TargetRegisterClass *RC = > TRI->getAllocatableClass(TII->getRegClass(II, i, TRI, *MF)); > > That returns GPRBaseRegs for RC, but it then decides to constrain it based > on type: > > if (i < NumResults && TLI->isTypeLegal(Node->getSimpleValueType(i))) { > const TargetRegisterClass *VTRC = > TLI->getRegClassFor(Node->getSimpleValueType(i)); > errs()<...

Hi Renato, On 06/25/12 12:13 AM, Renato Golin wrote: > Hi Karel, > > I understand this patch has already been merged (to 3.0), so don't > take my question as stopping the merge to head, I'm just making sure I > got it right... The rest looks correct. > > + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, > + CCIfType<[f64], CCAssignToReg<[D8, D9,

...emitted as comments "# 4-byte Reload” MachineInstrs will have multiple operands, ex: > %5 = MOV64rm %0, 1, $noreg, 0, $noreg and in order to know which operand is what, the X86 backend uses some enums and helper functions so that they can write code like: > const MachineOperand &BaseReg = MI->getOperand(Op+X86::AddrBaseReg); > const MCOperand &BaseReg = MI.getOperand(Op+X86::AddrBaseReg); for both MachineInstrs and MCInsts. > > Is it possible to have a X86 MachineInstr with a memory operand (i.e. X86II::getMemoryOperandNo >=0), that has no MachineMemOperan...

Hello, I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement, Segment. The former, if I understand it correctly, is used to hold a relationship back to IR load/store instructions. Is it possible to have

...ooks that preserves the existing behavior, > > It is not difficult. For example, > > > > For case one, we can define one function like > > virtual const SCEV* getTargetPreferredWinnerReg(const SCEV*& > ScaledReg, > > SmallVector<const SCEV *, 4>& BaseRegs, GlobalValue*& BaseGV) const; > > > > In NarrowSearchSpaceByPickingWinnerRegs, we can preserves the winner > > reg from target and winner reg from the original algorithm if this > function > > returns NULL, it is just like before > > > > For case...

...ter for implicit defs. Which >> is not your case, right? >> >> >> Though this code in CreateVirtualRegisters: >> >> const TargetRegisterClass *RC = >> TRI->getAllocatableClass(TII->getRegClass(II, i, TRI, *MF)); >> >> That returns GPRBaseRegs for RC, but it then decides to constrain it >> based on type: >> >> if (i < NumResults && TLI->isTypeLegal(Node->getSimpleValueType(i))) { >> const TargetRegisterClass *VTRC = >> TLI->getRegClassFor(Node->getSimpleValueType(i)); &...