similar to: Strange regalloc behaviour: one more available register causes much worse allocation

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

Dear R-users, I have a factor variable within my data frame which I derive week after week from a POSIXct variable using the cut(var,"weeks") command I have found in the chron package. The levels() command gives me: [1] "2009-03-30 00:00:00" "2009-04-06 00:00:00" "2009-04-13 00:00:00" "2009-04-20 00:00:00" "2009-04-27 00:00:00"

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

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 :

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

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

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

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

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.

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

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

On Mips 32 there is traditionally a 64 bit HI/LO register for the result of multiplying two 64 bit numbers. There are corresponding instructions to load the LO and HI parts into individual 32 registers. On Mips with the DSP ASE (an application specific extension), there are actual 4 such pairs of registers. Is there a way to have special purpose 64 bit registers without actually having to

> 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

Dear, I am looking at the Instructions defined in the XXXXInstrInfo.td where I can see a def record defined like below def ADD8rr : I8rr<0x0, (outs GR8:$dst), (ins GR8:$src, GR8:$src2), "add.b\t{$src2, $dst}", [(set GR8:$dst, (*add *GR8:$src, GR8:$src2)), (implicit SRW)]>; Now here I would like the to

Hi Joe, Le 11/05/2012 02:13, Joe Matarazzo a écrit : > I've been unable to come up with the TableGen recipe to match a > negated operand. My target asm syntax allows the following transform: > > FNEG r8, r5 > MUL r6, r8, r9 > > to > > MUL r6, -r5, r9 > > Is there a Pattern<> syntax that would allow matching *any* opcode (or > even some