[llvm-commits] mips16 patch 3

[reed kotler]

On 05/18/2012 10:07 PM, Jim Grosbach wrote:
> Won't HasMips32() return true even when compiling in mips16 mode? That is, whether the processor supports mips32 is orthogonal to which mode you're compiling for.
>
> For example, in the ARM backend, see hasThumb2() vs. isThumb2().
>
> -Jim
>
> On May 18, 2012, at 6:46 PM, reed kotler wrote:
>
>> This patch adds a predicate to existing mips32 and mips64 so that those instruction encodings can be excluded during mips16 processing.
>>
>> No additional testing is needed other than to assure that there is no regression from this patch.
>> <mips16_patch3.txt>_______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
In principle you are right but there are some other issues. We are doing 
mostly the same
thing with mips16 and micromips as ARM does with thumb and thumb2.

We have been using Mips32 and Mips64 in the compiler more to mean 
mips32-standard-encoding and mips64-standard-encoding instead of the 
pure meanings.

The method hasStandardEncoding as I implemented may be incorrect.
It does not break anything the way it is right now but I may need to 
modify it when I start to turn
on the mips16 encoding.

In principle Mips32 is one processor, and Mips64 is a superset of Mips32.
Mip16 and MicroMips are what we call ASEs (application specific 
extensions) and mostly they are  a mode where the instructions are 
encoded differently to save space.

I will clarify the method hasStandardEncoding with my next checkin.

We may continue to let Mips32=mips32-standard-encoding, 
mip64=mips64-standard-encoding,
mips16=mips32-mips16-encoding, micromips=mips32-micromips-encoding.

The are no processors that have mips64-mips16-encoding or 
mips64-micromips-encoding but there are specs for it so it could exist 
in the future but seems unlikely and in that case we could have 
mips64-mips16 and mips64-micromips as targets.

Traditionally you built a different compiler toolchain with gcc for 
mips32 or mips64 so -mips16
mean just use mips16 encoding for the compiler toolchain you are using. 
By doing it the way we did, we have greater makefile compatibility with 
gcc mips makefiles.

It's possible to switch modes between Mips16 and Mips32 but historically 
that has only been done at the compilation unit level but in the future 
we intend to do it within a compilation.