similar to: [LLVMdev] overriding InitLibcallNames?

Is it possible to assign the value of subtarget features using more complex expressions with code as opposed to using the mechanism that tablegen affords. For example, if Mips16 or Micro Mips is not present, then I want the subfeature "standard encoding". If I can't do this, then it requires me to write a more complex expression for the "standard encoding" expresions.

I'm working on the mips16. Mips16 is a mode of the Mips32 (or Mips64) processor. For the most part, it is a compressed form of the MIPS32 instruction set, though not all instructions are supported. Most of the same opcodes and formats are present though sometimes with some restriction. (The micro mips architecture is a true 16 bit compressed form of MIps32 though also with some

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 submit a patch to make it a virtual function so that I can override it and make it meaningful for Mips, as long as this method still exists. > > I want to add another register class for

On Jan 24, 2012, at 1:46 AM, Reed Kotler wrote: > Mips16 is a mode of the Mips32 (or Mips64) processor. For the most part, > it is a compressed form of the MIPS32 instruction set, though not all > instructions are supported. Most of the same opcodes and formats are > present though sometimes with some restriction. (The micro mips > architecture is a true 16 bit compressed form

On Fri, Jan 20, 2012 at 1:59 PM, reed kotler <rkotler at mips.com> wrote: > We are starting to look at the mips16 and micro mips ports. > > There are various design issues that people may have some good input on. > Especially in how to structure the TD files and other optimizer issues. > > Mips16 is sort of like thumb and Micro Mips like thumb2 as far as I > understand.

Mips16 mode has no floating point instructions. (Remember that mips16 is just an alternate decoder mode for the processor, mips32 or mips64 is the base processor). Currently with gcc for mips16, when there is floating point it generates a function call to emulate each floating point instruction. For mips 16 in llvm I want to just compile any function that has floating point, in mips32 mode.

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

We are starting to look at the mips16 and micro mips ports. There are various design issues that people may have some good input on. Especially in how to structure the TD files and other optimizer issues. Mips16 is sort of like thumb and Micro Mips like thumb2 as far as I understand. Mips16 or Micro Mips can live inside of either MIPS32 or MIPS64. In gcc, it's possible using attributes 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

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 submit a patch to make it a virtual function so that I can override it and make it meaningful for Mips, as long as this

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

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

On Mon, Jan 7, 2013 at 4:16 PM, reed kotler <rkotler at mips.com> wrote: > On 01/04/2013 07:45 PM, Eli Friedman wrote: >> >> On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: >>> >>> On 01/04/2013 06:08 PM, Eli Friedman wrote: >>>> >>>> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com>

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 01/04/2013 07:45 PM, Eli Friedman wrote: > On Fri, Jan 4, 2013 at 6:28 PM, reed kotler <rkotler at mips.com> wrote: >> On 01/04/2013 06:08 PM, Eli Friedman wrote: >>> On Fri, Jan 4, 2013 at 4:08 PM, reed kotler <rkotler at mips.com> wrote: >>>> I'm working on mips16 hard float which at a first approximation is just >>>> soft

Micro mips is really 100% .s compatible with mips32. There are no register field size constraints and such. It's a strict superset of mips32. For the gcc port, the assembler is basically the only thing we changed. The gcc port was just adding the ".micromips" directive to the .s file and maybe some tiny driver work. That is the quandary. The entire .td file would have to be

Reed, It's not clear to me that you need to do anything special here. If you define your MIPS16 register class as not containing SP, then any MIPS16 instructions that get selected and want to read from SP should get a COPY inserted from SP to a MIPS16 vreg. The coalescer should, ideally, get rid of extraneous copies for you. --Owen On Sep 20, 2012, at 10:48 PM, Reed Kotler <rkotler at

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.

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

This seems to work okay. I register both the Mips16 and non Mips16 passes of the instruction selector and then those return false if they are not supposed to be running. Make-check at least passes in this case. So in principle turn on the dual mode now and debug whatever misc is left. For this I insert another pass before the mips16 and non mips16 passes. On 03/27/2013 10:19 AM, Reed Kotler