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
[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
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.
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.