similar to: [LLVMdev] DebugInfo: Missing non-trivially-copyable parameters in SelectionDAG

Preamble -------- While working on an IR-level optimisation completely unrelated to register allocation I happened to trigger some really strange register allocator behaviour causing a large regression in bzip2 in spec2006. I've been trying to fix that regression before getting the optimisation patch committed, because I don't want to regress spec2006, but I'm basically fumbling in

> I've disassembled the failing MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 and compared it to > the one from the LLVM 3.6.0 test runs. There's nothing obvious. We've removed some useless > 'addiu $sp,$sp,0', eliminated two (seemingly redundant) sign extends, and the addresses of > functions+data has changed slightly. I've investigated further and I'm

enableAdvancedRASplitCost() does the same thing as ConsiderLocalIntervalCost, but as a subtarget option instead of a command-line option, and as I’ve said it doesn’t help because it’s a non-local interval causing the eviction chain (RAGreedy::splitCanCauseEvictionChain only considers the local interval for a single block, and it’s unclear to me how to make it handle a non-local interval). John

From: Akira Hatanaka [mailto:ahatanak at gmail.com] Sent: Wednesday, September 05, 2012 12:44 PM To: Villmow, Micah Cc: reed kotler; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] 64 bit special purpose registers Micah, Do you mean we should make GPR64 available to register allocator by calling addRegisterClass? addRegisterClass(MVT::i64, &GPR64RegClass) If we add register class GPR64, type

If no i64 reg classes are registered, then type-legalization will expand a 32b x 32b = 64b multiply node into a 32-bit mult node with two i32 results (for example, SMUL_LOHI). The problem is that there isn't an easy way to have RA assign two consecutive hi/lo registers to the two i32 registers, once the 64-bit result is split into two 32-bit results. Is there a constraint I can use (something

This can be done by declaring a register class with these registers and only using that register class as an operand in the instructions where it is legal. You then set as sub registers what you want to represent as the hi and lo registers for those 64bit registers. So something like this: def lo_comp : SubRegIndex; def hi_comp : SubRegIndex; def R1 : Register<1>; def R2 :

I try to define a register class def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] to simulate even/odd pair of GPR32 register. Actually, I just use GPR64 as a temporary register. My CPU just support i32 Integer type directly. I use FDR to save f64. def FDR : RegisterClass<"mytarget", [f64], 64,[FD0, FD1, ....] When I move f64 to even/odd pair register, I

On Jun 7, 2012, at 1:42 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On PPC, normal moves are encoded as OR instructions where the two > operands being ORed together are the same. These self moves, as it > turns out, come from things like this: > > %vreg18<def> = OR8To4 %vreg16, %vreg16; GPRC:%vreg18 G8RC:%vreg16 > > This is generated from the pattern: >

Hi Akira, Micah, On 05/09/2012 21:44, Akira Hatanaka wrote: > Micah, > > Do you mean we should make GPR64 available to register allocator by > calling addRegisterClass? > > addRegisterClass(MVT::i64, &GPR64RegClass) I have a related question to this thread. Does the RA use target lowering information? Because if it doesn't, you don't need to register your i64 reg

On Thu, Sep 6, 2012 at 10:02 AM, Reed Kotler <rkotler at mips.com> wrote: > Here is the problem explained more. > > Normally there is a 64 bit register that is the result of certain multiply > and divide instructions. > It's really 2 32 bit registers. > > This is like HI[0]/Lo[0] > > In fact there are four such pairs, only the 0th pair available to basic >

Dear Evan Chang: I register incorrect Register class for MVT::f64. I have fixed it. Thanks your advice. "-view-legalize-dags" is very good option. But I don't know why my LLC do not know " -view-legalize-type-dags" option. By the way, I use llvm 2.5 merged from llvm2.4. Best Regards, Ren Kun --- 09年3月31日，周二, Evan Cheng <echeng at apple.com> 写道： 发件人: Evan Cheng

On Thu, Sep 6, 2012 at 10:56 AM, Michael LIAO <michael.hliao at gmail.com>wrote: > On Thu, Sep 6, 2012 at 10:02 AM, Reed Kotler <rkotler at mips.com> wrote: > > Here is the problem explained more. > > > > Normally there is a 64 bit register that is the result of certain > multiply > > and divide instructions. > > It's really 2 32 bit registers.

> On Nov 11, 2017, at 11:03 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 11/11/2017 12:44 PM, Amara Emerson wrote: >> >>> On Nov 10, 2017, at 10:04 PM, Aditya Nandakumar <proaditya at gmail.com <mailto:proaditya at gmail.com>> wrote: >>>> >>>> The current DAGCombine, being constructed on top of

Here is the problem explained more. Normally there is a 64 bit register that is the result of certain multiply and divide instructions. It's really 2 32 bit registers. This is like HI[0]/Lo[0] In fact there are four such pairs, only the 0th pair available to basic multiply and divide. But DSP instructions have access to 4 , Hi[i],Lo[i], i=0..3 We want the register allocator to allocate

On 11/11/2017 12:44 PM, Amara Emerson wrote: > >> On Nov 10, 2017, at 10:04 PM, Aditya Nandakumar <proaditya at gmail.com >> <mailto:proaditya at gmail.com>> wrote: >>> >>> The current DAGCombine, being constructed on top of SDAG, has a kind >>> of built-in CSE and automatic DCE. How will things change, if >>> they'll change, in

Micah, Do you mean we should make GPR64 available to register allocator by calling addRegisterClass? addRegisterClass(MVT::i64, &GPR64RegClass) If we add register class GPR64, type legalization will stop expanding i64 operations because i64 is now a legal type. Then we will probably have to write lots of code to custom-lower unsupported 64-bit operations during legalization. Note that

I am trying to do the following pseudo-to-real instruction conversion: PseudoMFHI GPR32:$rd, ACC64:$ac -> MFHI GPR32:$rd Is there a way to tell the assembler, disassembler and instprinter to ignore the ACC64:$ac operand? I know I can use PseudoInstExpansion to accomplish this, but I just thought it would be convenient to have a flag for this, something like flag "DisableEncoding".

Hello, I'm trying to add pseudo 64-bit load and store instructions for AArch64, which should have latencies set to "1" while being otherwise exactly the same as normal load and store instructions. Various assertions fire (even different ones for the same binary, maybe something is uninitialized) and I can't understand what's wrong. Related pieces added by me: to

On Feb 19, 2009, at 8:26 PM, 任坤 wrote: > hi, Dear Evan Cheng: > > My cpu is i32 embeded CPU. I define pseudo register pair registers. > > In mytargetRegisterInfo.td: > def T0: RegisterWithSubRegs<"t0",[R0,R1]>; > ... > def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] > > In mytargetISelLowering.cpp: > I define i1, i8 ,

hi, Dear Evan Cheng: My cpu is i32 embeded CPU. I define pseudo register pair registers. In mytargetRegisterInfo.td: def T0: RegisterWithSubRegs<"t0",[R0,R1]>; ... def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] In mytargetISelLowering.cpp: I define i1, i8 , i16 and i32 are legal. 1. I still have problem. I save my function return double  value in