[LLVMdev] mips16 puzzle

Reed Kotler rkotler at mips.com
Thu Sep 20 23:44:53 PDT 2012


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 some places where we use C++ code that I think we could use 
just td files or maybe in some cases add some small extensions to tablegen.

Right now I'm just starting to debug and push upstream the whole mips 16 
port and am at about 65% passing all single source and 25% of multi 
source tests.


On 09/20/2012 11:03 PM, Owen Anderson wrote:
> 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 mips.com> wrote:
>
>> 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 instruction.
>>
>> In such cases, if I were writing assembly language code, I would move SP to a mips 16 register and then use it to do the store/load byte/haflword.
>>
>> It also then becomes a common subexpression because there may be multiple such accesses.
>>
>> It's like a temporary register alias.
>>
>> Add, Sub also have a way to reference memory using mips16 registers as a base address, so various operators on stack data are simplified.
>>
>> Any thoughts?
>>
>> Many ways to do this but I like simple ways. :)
>>
>> Tia.
>>
>> Reed
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list