[LLVMdev] various mips16 and micro mips issues

[Eli Friedman]

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