search for: gpr64

...example, it I want to move one 64-bit virtual reg to another, I'm trying to use the following pattern: def LoReg: OutPatFrag<(ops node:$Rd), (EXTRACT_SUBREG (i64 $Rd), isub_lo)>; def HiReg: OutPatFrag<(ops node:$Rd), (EXTRACT_SUBREG (i64 $Rd), isub_hi)>; def MOVi64rr : Pat<(set GPR64:$Rd, GPR64:$Rn), (REG_SEQUENCE GPR64, (MOVi32rr (HiReg GPR64:$Rn)), isub_hi, (MOVi32rr (LoReg GPR64:$Rn)), isub_lo)>; isub_hi and isub_lo are subregs of a single 64-bit virtual reg. When trying to compile it, im getting the following error: MOVi64rr: (set GPR64:i64:$R...

...y. I've investigated further and I'm fairly confident that r235869 (http://llvm.org/viewvc/llvm-project?view=revision&revision=235869) is the cause of this regression. The problem is these three definitions: // Bypass trunc nodes for bitwise ops. def : MipsPat<(i32 (trunc (and GPR64:$lhs, GPR64:$rhs))), (EXTRACT_SUBREG (AND64 GPR64:$lhs, GPR64:$rhs), sub_32)>; def : MipsPat<(i32 (trunc (or GPR64:$lhs, GPR64:$rhs))), (EXTRACT_SUBREG (OR64 GPR64:$lhs, GPR64:$rhs), sub_32)>; def : MipsPat<(i32 (trunc (xor GPR64:$lhs, GPR64:$rhs))),...

...>> >> One feature I think we ought to have that isn't on the requirements >> list already, is that I think we should have a means to support rules >> with more than one match root. For example (using SelectionDAG patterns): >> (set $dst1:GPR32, (i32 (load $ptr:GPR64))) >> (set $dst2:GPR32, (i32 (load (add $ptr:GPR64 4)))) >> into: >> (set $tmp:GPR64, (v2s32 (load $ptr:GPR64))) >> (set $dst1, (extractelt $tmp:GPR64, 0)) >> (set $dst2, (extractelt $tmp:GPR64, 1)) >> Or something along those lines (such as fusing div/mo...

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

...P] fi#-1: size=8, align=16, fixed, at location [SP] Function Live Ins: %X0 in %vreg0, %X1 in %vreg1, %X2 in %vreg2, %X3 in %vreg3, %X4 in %vreg4, %X5 in %vreg5, %X6 in %vreg6, %X7 in %vreg7 BB#0: derived from LLVM BB %1 Live Ins: %X0 %X1 %X2 %X3 %X4 %X5 %X6 %X7 %vreg7<def> = COPY %X7; GPR64:%vreg7 %vreg6<def> = COPY %X6; GPR64:%vreg6 %vreg5<def> = COPY %X5; GPR64:%vreg5 %vreg4<def> = COPY %X4; GPR64:%vreg4 %vreg3<def> = COPY %X3; GPR64:%vreg3 %vreg2<def> = COPY %X2; GPR64:%vreg2 %vreg1<def> = COPY %X1; GPR64:%vreg1 %vreg0<def> = COPY %X...

...ive across the JumpTableDest8). What's going on --------------- What this block looks like after live range splitting has happened is: 7352B bb.17.switchdest13: ; predecessors: %bb.3 successors: %bb.30(0x80000000); %bb.30(100.00%) 7360B %390:gpr32 = COPY $wzr 7364B %434:gpr64 = COPY %432:gpr64 7368B %429:gpr32 = COPY %427:gpr32 7376B %424:gpr32 = COPY %422:gpr32 7384B %419:gpr32 = COPY %417:gpr32 7392B %414:gpr32 = COPY %412:gpr32 7400B %409:gpr32 = COPY %407:gpr32 7408B %404:gpr32 = COPY %402:gpr32 7416B %399:gpr64 = COPY %397:gpr64 7424B...

...st" <llvmdev at cs.uiuc.edu> 日期: 2009,331,周二,1:04上午 This is probably instruction selection issue. I would look at the dag at various stafes of isel. Try -view-legalize-type-dags, -view-legalize-dags, etc. Evan On Mar 29, 2009, at 11:54 PM, 任坤 wrote: 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,...

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

Ok, thank you, I will implement it then. As far as I see this optimization should be done in AArch64LoadStoreOptimizer, is it right? From: Eli Friedman [mailto:efriedma at quicinc.com] Sent: Thursday, November 21, 2019 11:55 PM To: Kosov Pavel <kosov.pavel at huawei.com>; LLVM Dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] [ARM] Peephole optimization ( instructions tst +

...r pass. >>> >>> One feature I think we ought to have that isn't on the requirements list already, is that I think we should have a means to support rules with more than one match root. For example (using SelectionDAG patterns): >>> (set $dst1:GPR32, (i32 (load $ptr:GPR64))) >>> (set $dst2:GPR32, (i32 (load (add $ptr:GPR64 4)))) >>> into: >>> (set $tmp:GPR64, (v2s32 (load $ptr:GPR64))) >>> (set $dst1, (extractelt $tmp:GPR64, 0)) >>> (set $dst2, (extractelt $tmp:GPR64, 1)) >>> Or something along those line...

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 R0 and R1.  It is expanded into two i32. But my GPR64 is defined to save i64. llvm finds I...

Hi, I have tagged the 3.6.1-rc1 so testing can begin. We can always use more testers, so if you are interested in helping, let me know. Instructions for validating an LLVM release can be found here: http://llvm.org/docs/ReleaseProcess.html Reminder: We are using 3.6.0 as our baseline for regression testing. Thanks, Tom

...ss the JumpTableDest8). What's going on --------------- What this block looks like after live range splitting has happened is: 7352B bb.17.switchdest13: ; predecessors: %bb.3 successors: %bb.30(0x80000000); %bb.30(100.00%) 7360B %390:gpr32 = COPY $wzr 7364B %434:gpr64 = COPY %432:gpr64 7368B %429:gpr32 = COPY %427:gpr32 7376B %424:gpr32 = COPY %422:gpr32 7384B %419:gpr32 = COPY %417:gpr32 7392B %414:gpr32 = COPY %412:gpr32 7400B %409:gpr32 = COPY %407:gpr32 7408B %404:gpr32 = COPY %402:gpr32 7416B %399:gpr64 = COPY %397:gpr64 7424B...

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 , i16 and i32 are legal. > > 1. I still have problem. I save my function return double value in > R0 and R1. > It is expanded into two i32. But my GPR64 is de...

> On Nov 10, 2017, at 10:19 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 11/10/2017 11:12 AM, Amara Emerson via llvm-dev wrote: >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine instruction combiner/optimizer framework to be developed as part of the GISel pipeline. As we transition from

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 class. Ivan &...

...field bits<32> Inst = { 1, 0, 0, 1, 1, 0, 1, 1, 0, 1, 0, Rm{4}, > > Rm{3}, Rm{2}, Rm{1}, Rm{0}, 0, Ra{4}, Ra{3}, Ra{2}, Ra{1}, > > Ra{0}, Rn{4}, Rn{3}, Rn{2}, Rn{1}, Rn{0}, Rd{4}, Rd{3}, Rd{2}, > > Rd{1}, Rd{0} }; > > ... > > dag OutOperandList = (outs GPR64:$Rd); > > dag InOperandList = (ins GPR64:$Rn, GPR64:$Rm); > > string AsmString = "smulh $Rd, $Rn, $Rm"; > > list<dag> Pattern = [(set i64:$Rd, (mulhs i64:$Rn, i64:$Rm))]; > > ... > > bits<5> Rd = { ?, ?, ?, ?, ? }; > > bits<5&...

...has the following instruction definition: SMULHxxx { field bits<32> Inst = { 1, 0, 0, 1, 1, 0, 1, 1, 0, 1, 0, Rm{4}, Rm{3}, Rm{2}, Rm{1}, Rm{0}, 0, Ra{4}, Ra{3}, Ra{2}, Ra{1}, Ra{0}, Rn{4}, Rn{3}, Rn{2}, Rn{1}, Rn{0}, Rd{4}, Rd{3}, Rd{2}, Rd{1}, Rd{0} }; ... dag OutOperandList = (outs GPR64:$Rd); dag InOperandList = (ins GPR64:$Rn, GPR64:$Rm); string AsmString = "smulh $Rd, $Rn, $Rm"; list<dag> Pattern = [(set i64:$Rd, (mulhs i64:$Rn, i64:$Rm))]; ... bits<5> Rd = { ?, ?, ?, ?, ? }; bits<5> Rn = { ?, ?, ?, ?, ? }; bits<5> Rm = { ?, ?, ?,...

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 legalization will stop expanding i64 operations because i64 is now a legal type. [Villmow, Micah] You'll have to set everything that you don't s...

...something like register hints) to force RA to allocate consecutive registers? On Thu, Sep 6, 2012 at 5:06 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > 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 i...