<div dir="ltr">Hello all,<br>I'm currently working on a backend for the CPU within ESP32 MCUs. Which is a <span style="color:rgb(102,102,102);font-family:Roboto,arial,sans-serif;font-size:small;text-align:left;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Tensilica</span>

 Xtensa LX6 based CPU.<br>Some information about the CPU, it's an in-order design with flexible build options.<br>These build options include 32bit float instruction, "zero" overhead loops, MAC16 DSP operations, boolean registers, a 32 or 64 register large register file with 16 registers exposed in the ISA at any given moment, and SMP support.<div>The ISA can be flexible in size with both 24bit and 16bit instruction encodings and has a few other features.<br><br>I'm targeting the Hardkernel ODROID-GO[1] device with this backend, which is running an ESP32-WROVER chip which supports most of the features with its LX6 CPU core.</div><div><br></div><div>The work on my backend is coming up fast, with object files already being generated and running on the device with a weekend's worth of work or so. There is an interest in the community of this device to support more languages than the original GCC based toolchain supports. Which is where the LLVM backend comes in.<br><br>

<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">With that in mind, I do know that people in the past have attempted working on backends for Xtensa targets. All of these that I could find have died [2][3][4]. </span>I'm going to want to upstream this work, but I'm curious at what point it should be merged to cause as little friction as possible. Currently it is in a state where code is running but it is of course in heavy development and improving.<br><br>I'm planning on getting it to a stable state, where the LLVM backend can co-exist with the GCC toolchain. Which is going to be a longtime time investment. Their toolchain has a large amount of GCC-isms stuck in it that will take a fairly large amount of time to fully weed out in the near-term.</div><div>I'm not planning on dropping the code and vanishing for the foreseeable future due to this.</div><div><br></div><div>So the question is, at what point should I start upstreaming code? Right now, where it is working with a fairly minimal skeleton structure? Some arbitrary point in the future where it can compile most applications for these devices? Couple months to a year down the road when it has stabilized and bloated to the size of a regular target?<br><br>In addition, what sort of interest is there from other people in this mailing list for this target? Are there some Xtensa lovers hiding that would want this? Is the maintenance burden too much for people to want this to be upstreamed?<br><br>Leaving off, here are my current repos for the target. Loads of activity happen on them, probably won't be the same commit when you see this mail.</div><div><a href="https://github.com/Sonicadvance1/llvm-xtensa">https://github.com/Sonicadvance1/llvm-xtensa</a></div><div><a href="https://github.com/Sonicadvance1/clang-xtensa">https://github.com/Sonicadvance1/clang-xtensa</a><br><br></div><div><br></div><div>[1] <a href="https://www.hardkernel.com/main/products/prdt_info.php?g_code=G152875062626">https://www.hardkernel.com/main/products/prdt_info.php?g_code=G152875062626</a></div><div>[2] <a href="https://github.com/jdiez17/llvm-xtensa">https://github.com/jdiez17/llvm-xtensa</a><br>[3] <a href="https://github.com/NyxCode/xtensa-llvm">https://github.com/NyxCode/xtensa-llvm</a></div><div>[4] <a href="https://github.com/afonso360/llvm-xtensa">https://github.com/afonso360/llvm-xtensa</a></div></div>