similar to: [LLVMdev] register subclassing

Does anyone understand the purpose of : TargetRegisterInfo::getMinimalPhysRegClass ??? Why is there the presumption to use the minimal subclass? For Mips, it would work for me if we changed this to a virtual function and then I could override this to have it chose the proper register class based on the processor. I want to introduct a different register class for MIPS 16 but don't want

On 06/10/2014 05:51 PM, Pete Cooper wrote: > Hi Reed > > You can do this on the instruction itself by telling it 2 operands > must be the same register. For example, from X86: > > let Constraints = "$src1 = $dst" in > defm INSERTPS : SS41I_insertf32<0x21, "insertps">; > > Thanks, Hi Pete, Sorry. I should have been more specific. I'm

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 >

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.

It seems like it might be a legitimate complaint from the register allocator. It's trying to get an accumulator (not a general purpose register) and the accumulator is 64 bit. It's using a part of the Mips backend that I have not worked in so I have to research this a bit. The multiply instruction is a pseudo multiply in the mips backend and it needs the accumulator which a special

I ran into another issue with register scavenger. In my case, I don't need a place on the stack for an emergency spill slot. I have these free mips32 registers, that are not in general very useful for other things, for the emergency spill slot. I can move to and from mips16 (subset of mips32) registers and mips32 registers. I also have a situation where I need two free registers so then

You mean when I "explicity" use it by calling methods of register scavenger? Right now I'm just allocating virtual registers that will be resolved by the use of register scavenger and I'm also providing an override of the virtual method saveScavengerRegister. In Mips16, I have an extra mips 32 register (not usually very useful since it can only be used in a move instruction)

Hi Jim, One thing that seems strange to me is that if do a BuildMI, if you put a register inside the first parens, then it will treat it as a def, but if you just .addReg it won't (by default), even though it should know from the instruction definition. Seems like it should do that. Why would you want it to not do that? Reed On 02/18/2013 01:22 PM, Jim Grosbach wrote: > Hi Reed,

Here is a simple place I wanted to use it. ... On multiply, the result implicit is placed in a 64 bit hi/lo register. // // Format: MFLO rx MIPS16e // Purpose: Move From LO Register // To copy the special purpose LO register to a GPR. // def Mflo16: FRR16_M_ins<0b10010, "mflo", IIAlu> { let Uses = [LO]; let neverHasSideEffects = 1; } // // Pseudo Instruction for mult //

Turned out to be a rather simple fix. Just copied SP to a virtual register in the beginning of the function. Then added an extra operand to the DAGs with stack reference load/store, with the extra operand equal to this virtual register if the Parent of the address is a LOAD/STORE of an 8 or 16 bit quantity. It worked fine. When needed SP got copied to a mips 16 register and when the SP alias

On May 14, 2012, at 1:02 PM, reed kotler wrote: > Does anyone understand the purpose of : > > TargetRegisterInfo::getMinimalPhysRegClass ??? Barely. > Why is there the presumption to use the minimal subclass? The function can be traced back to a time when men were men and registers belonged to ONE register class. That concept doesn't make sense any longer, as LLVM supports and

Ok. That's a somewhat different problem, then. Devil will be in the details of what you want to do. A few options. First is to always have a standard frame pointer register available and reference off of that. Caveat: dynamic stack realignment and vararrays muck with that more than a bit. Second is what gcc is doing and reserve a register just for this in addition to the frame register.

I'm not sure. It certainly seems reasonable to me that the building could/should set default Define flags on operands based on the MCInstrDesc. Dunno why it doesn't. -Jim On Feb 19, 2013, at 7:14 PM, reed kotler <rkotler at mips.com> wrote: > Hi Jim, > > One thing that seems strange to me is that if do a BuildMI, if you put a register inside the first parens, then it

On 05/14/2012 02:17 PM, Jakob Stoklund Olesen wrote: > On May 14, 2012, at 1:02 PM, reed kotler wrote: > >> Does anyone understand the purpose of : >> >> TargetRegisterInfo::getMinimalPhysRegClass ??? > Barely. > >> Why is there the presumption to use the minimal subclass? > The function can be traced back to a time when men were men and registers belonged to

Reed, On May 14, 2012, at 3:45 PM, reed kotler <rkotler at mips.com> wrote: > On 05/14/2012 02:42 PM, Jakob Stoklund Olesen wrote: >> On May 14, 2012, at 2:28 PM, reed kotler wrote: >> >>> I'm not using getMinimalPhysRegClass. Some target independent code is using it. >> Probably PEI. >> >>> It makes trouble for us and I would like to

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

We already divided out our classes as you did for ARM. The problem here is that we have a store/load byte/halfword to/from a Frame object. We know at that time that it's not going to be possible to store it using SP because there is only such instructions for store/load of a word. What we would want to do is to move SP into a Mips 16 register and then do a indexed load/store off of that

On Sep 20, 2012, at 11:44 PM, Reed Kotler <rkotler at mips.com> wrote: > Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. > ARM has a similar problem. The InstrInfo

Hi Reed, The .td file "Defs = …" should be sufficient. The implicit uses and implicit defs are part of the MCInstrDesc data structure, which is shared by all instances of a given instruction. -Jim On Feb 17, 2013, at 2:22 PM, reed kotler <rkotler at mips.com> wrote: > If I put in my tablegen td file that a certain instruction implicitly sets a register, do I need to also do

Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it. There are