[LLVMdev] various mips16 and micro mips issues

[reed kotler]

On 01/20/2012 02:34 PM, Eli Friedman wrote:
> 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 or Micro Mips can live inside of either MIPS32 or MIPS64.
>>
>> In gcc, it's possible using attributes to change the default mode of
>> compilation for a given compilation unit.
>>
>> So you can start in Mips32 and for some function X go to Mips16 and then
>> go back to Mips32.
>>
>> So then would Mips16 and Micro Mips just be features that are added to
>> certain processors, in terms of the td files?
>>
>> I guess that clang can pass attributes through that can change a mode?
>>
>> I'm not sure exactly how ARM solves this right now.
>>
>> Also there is the other issue of the compiler deciding on it's own when
>> to switch say between Mips32 and Mips16 for example based on optimizer
>> criteria. I'm not sure if the Arm code generators are doing this at all.
>>
>> Tia for any input.
> In terms of the instruction descriptions, ARM/Thumb basically has both
> instruction descriptions embedded into the same set of .td files, and
> all the instructions are marked with a predicate, either [IsARM] or
> [IsThumb]. Depending on the computed target, the compiler knows which
> kind of instructions generate, and the assembler knows how to switch
> where appropriate.  There isn't really anything tricky here.
>
> The one key missing bit from what you're describing is that we don't
> have support for switching between ARM/Thumb in code-generation on
> per-function basis; in the ARM backend, the relevant switch affects
> the entire module.  There isn't anything conceptually difficult about
> per-function switching, but the actual code to support something like
> that doesn't exist at the moment.
>
> -Eli
1. This functionality has become more important for the mips16 port so I 
think I'd like to tackle adding this functionality to the compiler for 
switching modes on a per function basis, as gcc does.
gcc allows this as i mentioned.

2. What would be even better would be to allow it on a basic block basis.

3. Even better would be to allow the ability to try building a function 
or basic block using more than one method and chose the best.

#1 by itself would help out a lot. Any suggestions as to the best 
approach would be welcome.

mips16 has no floating point but the problem is that it can be mixed 
with mips32 code and on mips, floating point parameters are passed in 
floating point registers. remember that mips16 is just an instruction 
decoding mode and the real processor is either mips32 or mips64.

this means that while within a function you can use a variant of 
soft-float for mips16 (where the actual functions use real hardware), 
when you are passed or pass floating point arguments you must be able to 
load and store to floating point registers and that requires creating 
mips32 helper functions to do that; I'd rather just solve it more 
correctly using #1 and #2.

the mips16 fp mode in gcc is messy and i'd rather just solve it more 
appropriately.