Require windowed (and exception) for Xtensa ABI

[MabezDev]

Rust only supports the windowed Xtensa calling convention on all upstream targets (esp32 family). Mark windowed and exception as ABI-required features so a mismatched -Ctarget-cpu cannot silently change the ABI.

Discussion: #160530 (comment)

• I did not use an LLM to create a change in this PR.
• I used an LLM to create a change in this PR, and I have explained below how it was used.

r? @RalfJung

[rustbot]

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

[RalfJung]

Thanks!

Looking at the LLVM backend, it seems some registers are only available with certain target features:

 if (Subtarget.hasSingleFloat()) {
addRegisterClass(MVT::f32, &Xtensa::FPRRegClass);
}
if (Subtarget.hasBoolean()) {
addRegisterClass(MVT::v1i1, &Xtensa::BRRegClass);
}

Does that mean these target features also affect the ABI? I think hasSingleFloat corresponds to "fp" and hasBoolean to "bool".

[RalfJung]

Also, if we are adding the ABI checks anyway, could you also add the other part of them which goes into this big match? Seems like we only support a single ABI for Xtensa for now so the checks should be the same as for wasm.

[apiraino]

hey @MabezDev

as per our LLM policy, please disable Copilot in your GitHub settings and don't trigger unprompted reviews from bots in our repository.

Thanks

[RalfJung]

@MabezDev friendly reminder that this PR is waiting for you to react to my feedback. :)
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

Target features are being changed; ensure all ABI effects are being accounted for

cc @RalfJung

[rustbot]

Target consistency checks are being changed

cc @RalfJung

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[MabezDev]

Sorry for the delay, juggling a few things at the moment :).

@rustbot ready

[RalfJung]

Thanks! This question is still open:

Looking at the LLVM backend, it seems some registers are only available with certain target features:

 if (Subtarget.hasSingleFloat()) {
addRegisterClass(MVT::f32, &Xtensa::FPRRegClass);
}
if (Subtarget.hasBoolean()) {
addRegisterClass(MVT::v1i1, &Xtensa::BRRegClass);
}

Does that mean these target features also affect the ABI? I think hasSingleFloat corresponds to "fp" and hasBoolean to "bool".

[MabezDev]

Ah, sorry, forgot to write a reply. fp/bool do not modify the ABI, so I left them out here.

[RalfJung]

Okay, thanks. I wonder what the LLVM backend is doing there then. I guess floats are always passed in memory or in integer registers, so that the f32 register class does not matter?

@bors r+ rollup

[rust-bors]

📌 Commit 8a446b5 has been approved by RalfJung

It is now in the queue for this repository.

[RalfJung]

FWIW if you know what is up with addRegisterClass(MVT::f32, &Xtensa::FPRRegClass); I'd still appreciate getting to the bottom of this. For all other LLVM backends, that usually indicates that there is some sort of ABI effect here. What makes Xtensa special?