Add avr_target_feature

[taiki-e]

This adds the following unstable target features (tracking issue: #146889):

• The following two are particularly important for properly supporting inline assembly:

  • tinyencoding: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also Support AVRTiny devices in AVR inline assembly #146901)
  • lowbytefirst: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876)

• The followings help recognizing whether specific instructions are available:

  • addsubiw
  • break
  • eijmpcall
  • elpm
  • elpmx
  • ijmpcall
  • jmpcall
  • lpm
  • lpmx
  • movw
  • mul
  • rmw
  • spm
  • spmx
  • sram

  Of these, all except addsubiw, break, ijmpcall, lpm, rmw, spm, spmx, and sram have corresponding conditional codes in avr-libc. LLVM also has des feature, but I excluded it from this PR because DES is insecure.

LLVM also has smallstack, wrappingrjmp, and memmappedregs features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something.

(The feature names are match with definitions in LLVM.)

cc @Patryk27 @Rahix
r? workingjubilee

@rustbot label +O-AVR +A-target-feature

[rustbot]

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

[taiki-e]

As for sram, this is the minimum requirement for C/C++ in both avr-gcc and clang (llvm/llvm-project@4bf6e83), and likely for Rust as well, so it is probably better to handle this not as a target feature here, but another way (such as rejecting compilation if it is not enabled).

[Patryk27]

nit: what about name collisions? 👀

The RFC doesn't seem to mention this, but I can see AVR's break (or other "generic" word like mul) accidentally colliding with another arch in future - on the other hand, keeping the mapping 1:1 with LLVM (FeatureBREAK in this case) is important as well, IMO.

Other than that LGTM.

[taiki-e]

Target feature name collisions with other architectures are fine. (e.g., the aes target feature exists on x86/x86_64 (AES-NI) and arm/aarch64/arm64ec (FEAT_AES) respectively.)

[taiki-e]

As for sram, this is the minimum requirement for C/C++ in both avr-gcc and clang (llvm/llvm-project@4bf6e83), and likely for Rust as well, so it is probably better to handle this not as a target feature here, but another way (such as rejecting compilation if it is not enabled).

Looking at the LLVM issue, in Rust, I guess it might work if we use no_main and put all processing inside global_asm and/or external assemblies...

[workingjubilee]

cc @rust-lang/lang informational-only: letting you know about this target's features because it is particularly interesting in terms of it being on the boundary of what Rust can support.

I think that we should indeed either ignore it or just error if someone tries to say -Ctarget-feature=-sram to the compiler. It is a rare case of "Here's a nickel, kid, go buy yourself a real computer" being an actually literally valid suggestion, even with 2025's inflation. The newest "AVR1" chips are so old that even products with 25-year lifecycles should have killed them off by now.