llvm dev - Jan 2012 - [LLVMdev] various mips16 and micro mips issues

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.

Reed

On Friday, January 20, 2012 03:59:14 PM reed kotler
wrote:
> We are starting to look at the mips16 and micro mips ports.
[snip]

I'm looking forward to seeing the mips16 and micro mips support.

As an aside, the Mips code generator as it exists looks pretty solid so far in 
my testing. As I've been building the NetBSD library (and other stuff) using
my
ELLCC copy of clang/LLVM only the Mips processor turned up zero bugs in my 
regression test suite. The other processors all failed one or more tests. A 
failure doesn't mean clang/LLVM failed necessarily. Some of the bugs may be
in
the library itself (system call incompatabilites, for example) and a few are 
in QEMU, which I use to run the test suite.

Nice stuff!

-Rich

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

Thanks. We work really hard on compiler testing.

On 01/20/2012 02:29 PM, Richard Pennington wrote:
> On Friday, January 20, 2012 03:59:14 PM reed kotler wrote:
>> We are starting to look at the mips16 and micro mips ports.
> [snip]
>
> I'm looking forward to seeing the mips16 and micro mips support.
>
> As an aside, the Mips code generator as it exists looks pretty solid so far
in
> my testing. As I've been building the NetBSD library (and other stuff)
using my
> ELLCC copy of clang/LLVM only the Mips processor turned up zero bugs in my
> regression test suite. The other processors all failed one or more tests. A
> failure doesn't mean clang/LLVM failed necessarily. Some of the bugs
may be in
> the library itself (system call incompatabilites, for example) and a few
are
> in QEMU, which I use to run the test suite.
>
> Nice stuff!
>
> -Rich
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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.