Merge into main branch rust-lang/rust?

[luojia65]

By now developers have to compile whole custom Rust toolchain to work with xtensa isa. Is there any possibility to merge xtensa instruction set support into main branch Rust? Then developers can install them easily by using rustup toolchain add command.

[mcilloni]

I don't think this can be done until the Xtensa backend is merged into upstream LLVM, but I could be wrong.

[MabezDev]

@mcilloni is correct, Rust won't accept Xtensa support upstream without atleast an experimental backend in LLVM upstream.

With the riscv chips, we've already upstreamed everything we can.

[stappersg]

Where to check the status?

URLs that I'm missing:

• LLVM xtensa branch
• issue that describes the merge of xtensa into LLVM
• issue that describes the merge of "LLVM xtensa" into Rust

[MabezDev]

• https://github.com/espressif/llvm-project
• Tracking Issue for merging to upstream (LLVM-57) espressif/llvm-project#4
• This issue.

[paulocsanz]

espressif/llvm-project#4 implies that all of the repo's changes have been merged to upstream LLVM, although the PR hasn't been closed yet.

What are the next steps?

[igrr]

We have indeed got the first patch set merged into LLVM, however that set of patches is not yet sufficient for a working Rust compiler.
We will update the tracking issue with the next series of patches as soon as we post them for review. You can find the entire set of Xtensa patches here: espressif/llvm-project#62.

[noahbliss]

Hey guys, just wanted to ping this as it seems there is some new traction over at the tracking issue espressif/llvm-project#4 seems this might be coming pretty close

[jessebraham]

seems this might be coming pretty close

My understanding (somebody can correct me if I'm wrong) is that there are still a large number of patches which need to be merged into LLVM before full Xtensa support is realized. Once this is complete, it will take time for these changes to propagate into Rust as well.

[SergioGasquez]

Quick update as we've made some progress about upstreaming our Rust patches, the following PRs were merged:

• Teach rustc about the Xtensa VaListImpl rust-lang/rust#127565
• Add +forced-atomics feature to esp32s2 no_std target rust-lang/rust#133599
• Add std Xtensa targets support rust-lang/rust#126380
• Add no_std Xtensa targets support rust-lang/rust#125141
• Remove - from xtensa targets cpu names rust-lang/rust#138064

We are still awaiting on the LLVM upstreaming effort to be able to continue upstreaming our Rust patches.

[Skgland]

In the latest comment on the llvm upstreaming tracking issue there are no open llvm tasks only some clang task. Does that mean the LLVM upstreaming is now no longer a blocker? Or what is missing now?

[SergioGasquez]

I'm not sure if all the required functionality of LLVM is already merged upstream, but we would still need to wait for Rust to use the LLVM release that includes the Xtensa changes, which is about 6 months after release iirc

[823984418]

As of now, I have been trying to compile ESP32 code using the nightly compiler and have encountered the following issues:

Directly use the xtensa-esp32-none-elf target

[build]
target = "xtensa-esp32-none-elf"

I got

data-layout for target `xtensa-esp32-none-elf-4712693060684062482`, `e-m:e-p:32:32-v8:8:8-i8:8:32-i16:16:32-i64:64-n32`, differs from LLVM target's `xtensa-none-elf` default layout, `
2e-m:e-p:32:32-i8:8:32-i16:16:32-i64:64-n32`

Use custom_target.json

[build]
target = "xtensa-esp32-none-elf.json"

Due to the fact that some commit of LLVM (add esp32 CPU and atomic access) has not been obtained by rust/llvm yet:
"cpu": "generic",
-fp
-s32c1i
-highpriinterruptslevel7
"max-atomic-width": 0,

xtensa-esp32-none-elf.json:

{
  "arch": "xtensa",
  "cpu": "generic",
  "crt-objects-fallback": "false",
  "data-layout": "e-m:e-p:32:32-i8:8:32-i16:16:32-i64:64-n32",
  "features": "+density,+loop,+mac16,+windowed,+bool,+sext,+nsa,+clamps,+minmax,+mul32,+mul32high,+mul16,+dfpaccel,+threadptr,+div32,+dcache,+debug,+exception,+highpriinterrupts,+coprocessor,+interrupt,+rvector,+timers3,+prid,+regprotect,+miscsr",
  "emit-debug-gdb-scripts": false,
  "linker": "xtensa-esp32-elf-gcc",
  "linker-flavor": "gnu-cc",
  "llvm-target": "xtensa-none-elf",
  "max-atomic-width": 0,
  "metadata": {
    "description": "Xtensa ESP32",
    "host_tools": false,
    "std": false,
    "tier": 3
  },
  "panic-strategy": "abort",
  "relocation-model": "static",
  "target-pointer-width": "32",
  "vendor": "espressif"
}

Cannot use inline assembly

xtensa-lx inline assembly is unsupported on this target

This seems to be because the commit has not yet been sent upstream:

• Xtensa asm! implementation #68

Some other issues, but I think this is because I turned off all atomic types

---

core/alloc was compiled normally, so I think we are very close to using the default compiler directly!

[MabezDev]

@823984418 it is indeed close, at least for building simple programs. Thanks for hint about the asm patch, I need to find some time to clean up the asm patch and submit it upstream. I'll do that soon.