Avoid emulating wider atomics

Generally, Rust eschews emulating atomics where it can.
This is done precisely so people can write interrupt handlers in Rust,
without accidentally arriving in other interrupt handlers,
or other complications that such things tend to induce.

No solution is yet proposed for the xtensa-esp32s2-espidf target.
However, it would be less-than-ideal if an ecosystem grew up around
Rust-on-Xtensa that was dependent on something historically rejected by
upstream Rust in the cases where it was easily avoidable.

Author: workingjubilee

compiler/rustc_target/src/spec/xtensa_esp32_espidf.rs

@@ -20,12 +20,11 @@ pub fn target() -> Target {
             cpu: "esp32".into(),
             linker: Some("xtensa-esp32-elf-gcc".into()),
 
-            // The esp32 only supports native 32bit atomics. However, esp-idf will emulate 64bit atomics 
-            // so we claim a max atomic width of 64 here.
-            max_atomic_width: Some(64),
+            // esp-idf can emulate 64-bit atomics, but Rust eschews non-hardware atomics
+            max_atomic_width: Some(32),
             atomic_cas: true,
 
             ..super::xtensa_base::opts()
         },
     }
-}
+}

compiler/rustc_target/src/spec/xtensa_esp32s3_espidf.rs

@@ -20,12 +20,11 @@ pub fn target() -> Target {
             cpu: "esp32-s3".into(),
             linker: Some("xtensa-esp32s3-elf-gcc".into()),
 
-            // The esp32s3 only supports native 32bit atomics. However, esp-idf will emulate 64bit atomics 
-            // so we claim a max atomic width of 64 here.
-            max_atomic_width: Some(64),
+            // esp-idf can emulate 64-bit atomics, but Rust eschews non-hardware atomics
+            max_atomic_width: Some(32),
             atomic_cas: true,
 
             ..super::xtensa_base::opts()
         },
     }
-}
+}