The old syntax for target_feature
allowed enabling or disabling arbitrary features, which was convenient on ARM platforms where deciding per-function whether to use the ARM or Thumb ISA by enabling or disabling the thumb-mode
feature was possible and even desirable. (For example: I'm writing Rust code which ends up running on a Game Boy Advance. Most code is compiled as Thumb for speed since the Game Pak only has a sixteen-bit bus, but if I provide an interrupt dispatcher it has to be compiled as ARM code because of how Nintendo wrote the firmware.)
The new target_feature
doesn't define syntax for disabling features, only enabling them; this makes it better-suited for the things it was being used for and makes thumb-mode
stand out: if a target is -avx
, it doesn't have something else instead of AVX instructions, but a -thumb-mode
target has a whole different instruction set to a +thumb-mode
target.
As such, rather than extending target_feature
in ways which risk trying to make it into both a floor wax and a dessert topping it seems more appropriate to suggest new function attributes #[arm]
and #[thumb]
. These would disable and enable thumb-mode
for the annotated function in the same way #[target_feature = "±thumb-mode"]
used to; annotating the same function with both results in a compile-time error. (I can't imagine anyone doing this deliberately, and it's good for the compiler to catch typos.) LLVM already knows how to provide the necessary interworking shims, so as far as I can tell everything should just work.
I'm unsure how inline assembly should be handled; some instructions which are legal in ARM mode are illegal in Thumb mode and vice versa, and an obvious extension of the two function attributes is to use them in cfg(...)
in order to generate different code in ARM and Thumb mode. An example: the Game Boy Advance provides several library functions using the swi
instruction, but in ARM mode the argument needs to be left-shifted sixteen bits, creating an invalid instruction if the file is processed in Thumb mode. Currently it's not really a problem since you can't decide one function should be compiled to the ARM ISA in an otherwise Thumb function.