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