rustc is too strict about reserved registers on ARM

[Skirmisher]

Recently, this commit came to my attention, as it added r9 to the list of LLVM-reserved registers on ARM according to rustc, breaking existing inline asm. I decided to look into this further, and found this page (section "Restrictions") which concisely states under what conditions certain registers are reserved in the ABI (with regards to armclang as described in the page, but it applies more generally). The relevant points are:

• If RWPI (read-write position independent) code is enabled, R9 is reserved.
• If needed, R7 is reserved for the frame pointer in T32 mode, and R11 is reserved in A32 mode.

However, rustc reserves these registers unconditionally. This seems incorrect, as both RWPI and frame pointers can be disabled via codegen options or a custom target. In our case, the custom target file (armv4t-none-eabi.json) has both "eliminate-frame-pointer": true and "relocation-model": "static" set, but rustc will reject uses of r9 and r11 with their respective error messages ("r9 is used internally by llvm" and "frame pointer (r11) cannot be used as an operand").

[Lokathor]

The gba crate (thumbv4t-none-eabi target) also got hit with this.

[Skirmisher]

Okay, so the codegen backend situation has changed a lot since this target file was first generated, and eliminate-frame-pointer was replaced a while back with frame-pointer which defaults to MayOmit—no longer implying a guarantee, mainly because a different codegen backend can make arbitrary decisions about the frame pointer (and it's unclear how or whether this setting eliminated the frame pointer in LLVM in the first place). I was not aware of the codegen backend abstraction work or anything else when filing this issue.

At any rate, R9 restriction is easiest to fix since the relocation model info is just There, and Arm's documentation is very clear about when it is and is not reserved. See my new pull request here with more info. The rest can be figured out later.