Repository navigation
Xtensa esp32s3 targets do not work with upstream LLVM #162828
Description
In #160643, we made it so that the "windowed" target feature is marked as "required", because it affects the ABI and we do not intent to support cases where it is missing.
However, two of our Xtensa targets actually do not have that target feature: xtensa-esp32s3-none-elf and xtensa-esp32s3-espidf. This results in warnings any time the target is used:
$ rustc +nightly --print=cfg --target=xtensa-esp32s3-none-elf
'esp32s3' is not a recognized processor for this target (ignoring processor)
'esp32s3' is not a recognized processor for this target (ignoring processor)
warning: target feature `windowed` must be enabled to ensure that the ABI of the current target can be implemented correctly
|
= note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #162235 <https://github.com/rust-lang/rust/issues/162235>
warning: target feature `exception` must be enabled to ensure that the ABI of the current target can be implemented correctly
|
= note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #162235 <https://github.com/rust-lang/rust/issues/162235>
None of the other targets sets the feature explicitly, so I can only assume that the "esp32" and "esp32s2" CPUs imply "windowed" but "esp32s3" no longer implies "windowed". That seems odd. Is this a bug in the LLVM information about Xtensa CPUs?
Activity
[-]Xtensa targets do not respect ABI requirements[/-][+]Xtensa esp32s3 targets do not respect ABI requirements[/+]RalfJung commentedon Sep 15, 2026
Looking at LLVM it seems like "esp32s3" is simply not a valid processor string at all?
https://github.com/llvm/llvm-project/blob/299a09b38b4bd9d6b78e4c7a0c73b0cd671ce081/llvm/lib/Target/Xtensa/XtensaProcessors.td
I am surprised that this does not cause an error.
EDIT: Oh, it does
RalfJung commentedon Sep 15, 2026
The espressif fork of LLVM does have that CPU:
https://github.com/espressif/llvm-project/blob/release/esp_22.x/llvm/lib/Target/Xtensa/XtensaProcessors.td
But we should not have targets in upstream Rust that require a non-upstream LLVM.
Seems to me like we should remove the xtensa-esp32s3 targets for now as apparently LLVM support for that CPU is still missing.
This target got added in #125141, Cc @davidtwco
[-]Xtensa esp32s3 targets do not respect ABI requirements[/-][+]Xtensa esp32s3 targets do not work with upstream LLVM[/+]Urgau commentedon Sep 16, 2026
Just noting that this was known at the time as well:
RalfJung commentedon Sep 16, 2026
Yeah... I don't think it was a good idea to land the targets in that state, but given that 2 years later upstreaming still hasn't happened for esp32s3, and this is now causing FCWs, I think it is time to correct course. (There are 6 xtensa targets and 4 of them do have upstream support in LLVM now. This issue is only about the two targets that still have no upstream support.)
RalfJung commentedon Sep 16, 2026
Note that the policy has since been clarified to say
rustc's supported backends from any host target. (Having support in a fork
of the backend is not sufficient, it must be upstream.)
The parenthetical was added after these targets were added. It was always implied but we made it explicit in #125708.
[-]Xtensa esp32s3 targets do not work with upstream LLVM[/-][+]Xtensa esp32s3 target does not work with upstream LLVM[/+][-]Xtensa esp32s3 target does not work with upstream LLVM[/-][+]Xtensa esp32s3 targets do not work with upstream LLVM[/+]MabezDev commentedon Sep 16, 2026
The chip features in the LLVM backend are essentially just shortcuts for an array of target features. All Espressif ESP32 variants have the windowed feature.
I appreciate that this is annoying, but thankfully the upstream LLVM PR is now merged: llvm/llvm-project#220393. This was unfortunately one of the last patches in the patch set to get merged because it relies on upstreaming basically everything else.
I'd really prefer not removing the target, so how about instead of setting
target_cpu, I instead set the target feature flags myself that replicate theesp32s3feature? All the CPU features are already there in LLVM, it's literally just the shorthand version that isn't there yet (well, and some DSP bits bit rustc doesn't care about that yet). How does that sound?RalfJung commentedon Sep 16, 2026
Ah, I didn't realize I was racing with the PR that adds this CPU to LLVM. Talk about timing. ;)
If that means using the target with upstream LLVM 23 produces no warnings from LLVM or rustc, that's fine for me. I trust your judgment as target maintainer about the correctness of that target spec.
nikic commentedon Sep 16, 2026
Seeing llvm/llvm-project#220393, I don't see how just spelling out the target features could be equivalent to everything implemented in that PR.
MabezDev commentedon Sep 16, 2026
Most of that PR is DSP related, which isn't required for testing in rust's CI. I would essentially be porting this: https://github.com/llvm/llvm-project/pull/220393/changes#diff-e0e19fc57041fe4cccdc1b82341952d04cfa43abb40699a5a37f2873880d9237R34-R38 to the rust target definition.
Rollup merge of rust-lang#162840 - RalfJung:tier-3-target-cpu, r=mati865
Rollup merge of rust-lang#162840 - RalfJung:tier-3-target-cpu, r=mati865
Rollup merge of rust-lang#162840 - RalfJung:tier-3-target-cpu, r=mati865
Unrolled build for #162840 in rollup 164699