similar to: [LLVMdev] another mips16 puzzle

Usually we do all the accessing of stack variables via the SP register. When the stack size is dynamic we need a frame pointer, FP. There is a traditional FP register for MIPS, but FP is not a mips16 register so in general it has little use for mips16 because you can't directly address it except in the move instruction when moving from/to mips16 to mips32 register. There are several ways

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 > float but calls different library routines. Those different library routines > are just an implementation (in mips32 mode) of soft float using mips32 > hardware instructions. This part is already done. (mips16 mode has no

For example: /home/rkotler/llvm/install/bin/llc -mcpu=mips16 hf16_2.ll -march=mipsel -relocation-model=pic -o hf16_2.s -O3 -mips16-hard-float -soft-float 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

I'm working on mips16 hard float which at a first approximation is just soft float but calls different library routines. Those different library routines are just an implementation (in mips32 mode) of soft float using mips32 hardware instructions. This part is already done. (mips16 mode has no floating point instructions). The next level of this that I am working on now is the ability to

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>

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

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

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

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 >>> float but calls different library

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 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 >> float but calls different library routines. Those different library routines >> are just an implementation (in mips32 mode) of soft float using mips32 >>

Trying to think of a clever way to do something.... On Mips 16, the SP (stack pointer) is not a directly accessible register in most instructions. There is a way to move to and from mips 16 registers (subset of mips32) and mips32 registers. For the load/store word instructions, there are forms which implicitly take SP. However, for store/load byte and store/load halfword, there is no such

Does not seem that anyone is using the more advanced features of RegScavenger On 02/05/2013 01:09 PM, reed kotler wrote: > I ran into a case in Mips16 where I need two registers. > > The problem arises from the fact that SP is not a mips16 register. > You can implicitly use it in load/store and, move it to/from a mips16 > register and add small immediate values to it but

I ran into a case in Mips16 where I need two registers. The problem arises from the fact that SP is not a mips16 register. You can implicitly use it in load/store and, move it to/from a mips16 register and add small immediate values to it but that's it. It's not in general a problem for me because there are a bunch of mips32 registers that are hard to use in mips16 so at this time, I

I have some test scripts I use for testing floating point interoperability between mips16 and mips32. There are lots of combinations and there are subtle issues that make them slightly different and they need to all be tested. For a very basic test, I have a program which has a sample function of all floating point signatures that are effected by this. Basically an ABI test for this. This

I'm starting to look more seriously at the problem of being able to running TargetLowering on a per function basis. In particular, I want to be able to compile functions as mips16 or mips32 , mixing them within a single compilation unit. It would be great if some more experienced people in this overall structure of the compiler would give their 2c because I'd hate to spend a lot of

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

No. forward() is working correctly. All virtual register references must be resolved before calling it. -Jim On Feb 5, 2013, at 4:05 PM, Reed Kotler <rkotler at mips.com> wrote: > So what I realized is that you can't use the simple scavenger trick where you create the virtual register and use the more advanced features. > > This is because you can't call forward() in any

So what I realized is that you can't use the simple scavenger trick where you create the virtual register and use the more advanced features. This is because you can't call forward() in any form if there are virtual registers being used by any of the instructions in the basic block. This will cause forward to fail. Maybe this is a bug in forward() On 02/05/2013 02:51 PM, Reed Kotler

I'm happy to send you my patch as it stands today. It's not cleaned up yet all or tested thoroughtly but you can look at what I'm doing and maybe suggest some alternate paths and if it's not a matter of redoing everything, I would consider making some changes. Here is a sample stub: Consider this line of code: extern float fpff(float); We have no idea if this is a mips16 or