[llvm-commits] mips16 patch 3

[reed kotler]

I'm working on the next patch this weekend so would prefer to just check 
this in and
clean up the method hasStandardEncoding on the next patch, if it needs it.

We do a fair amount of testing before checkins and the current patch 
passes all our tests with no issues.

On 05/19/2012 04:02 PM, reed kotler wrote:
> 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.
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits