search for: baseregs

In looking at the code in ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is the following condition for not creating tbb-based jump tables: // The instruction should be a tLEApcrel or t2LEApcrelJT; we want // to delete it as well. MachineInstr *LeaMI = PrevI; if ((LeaMI->getOpcode() != ARM::tLEApcrelJT &&

Hi Jakob, You're the unfortunate soul who last touched the constant island pass, right? Do you happen to have any insight for Daniel? Chad On Tue, Jul 23, 2013 at 9:55 AM, Daniel Stewart <stewartd at codeaurora.org>wrote: > In looking at the code in > ARMConstantislandPass.cpp::optimizeThumb2JumpTables(), I see that there is > the following condition for not creating

On Jul 29, 2013, at 6:50 AM, Chad Rosier <chad.rosier at gmail.com> wrote: > Hi Jakob, > You're the unfortunate soul who last touched the constant island pass, right? Do you happen to have any insight for Daniel? Sorry, no. I don't remember working with that particular bit of code. You could try digging through the commit logs. Thanks, /jakob > On Tue, Jul 23, 2013 at

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

Hi All, In the target I am working, we comes cross a situation that the loop strength reduction could deliver a better result but currently not, because 1. the algorithm narrows search space by winner registers without considering the target preferred format. (NarrowSearchSpaceByPickingWinnerRegs) 2. Cost comparison solely favors the number register without considering other

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

On 06/29/12 11:12 PM, Renato Golin wrote: > 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

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

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

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

Hi David, I'm catching up on email at the moment so I don't know if you've done this, but patches should go to llvm-commits for review if you wouldn't mind. Thanks! -eric On Thu Dec 12 2013 at 8:39:19 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 > It also fixes a test which was requiring

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

On Mar 13, 2013, at 4:37 PM, Yin Ma <yinma at codeaurora.org> wrote: > Hi All, > > In the target I am working, we comes cross a situation that the loop strength reduction > could deliver a better result but currently not, because > 1. the algorithm narrows search space by winner registers without considering > the target preferred format.

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

Hello Mircea, > On 8 Mar 2018, at 18:52, Mircea Trofin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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,

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

...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)); &g...