[spec] Add reserved version for Xtensa architecture

[thewilsonator]

See also ldc-developers/ldc#4725

cc @TurkeyMan is Xtensa ESP always 32-bit? What to do about Xtensa-S2/Xtensa-S3? I assume they will be specified in the target triple and any information they provide can be done through other means (e.g. __traits(getTargetInfo))

[dlang-bot]

Thanks for your pull request and interest in making D better, @thewilsonator! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[TurkeyMan]

ESP32 is LX6, -S2,S3 are LX7, which has some additional instructions. It's always 32bit as far as I know. LX7 has some rudimentary SIMD stuff, a MAC instruction in particular is something the backend will want to take advantage of.

It'll be nice to feed as much knowledge as possible through getTargetInfo as you say; the whole point of the Xtensa platform is to be extensible, determining if specific ISA features are present for the selected target will be more useful than comparing the target to a whole bunch of known implementations in software...

[TurkeyMan]

See here: https://github.com/espressif/llvm-project/blob/xtensa_release_18.1.2/llvm/lib/Target/Xtensa/Xtensa.td#L194
They specify the processors from a compound list of features... how much trouble is it to expose that list via getTargetInfo somehow? It seems like the notion of feature sets is already known to LLVM... of software can query those feature flags, it can use the hardware as it's available.

[JohanEngelen]

@TurkeyMan Doesn't LDC's __traits(targetHasFeature, ...) cover what you need? (the functionality that you want should not be covered by a bunch of version identifiers)

[TurkeyMan]

Sure. How do we know what all those features are named to test for them?

[thewilsonator]

Yeah that sounds like CPU variants, not something that should have different version.
I suspect that the different subtarget features will be handled by __traits(targetHasFeature, ...) and the different CPU variants will be handled by __traits(getTargetCPU) (which will return e.g. "esp8266" or "esp32s3")

Sure. How do we know what all those features are named to test for them?

the string is the first argument of SubtargetFeature in feature foo in SubtargetFeature<"foo", ...>

import std.stdio;
void main() {
  writeln("CPU = ", __traits(targetCPU));
  writeln("Has 'sse4.1' = ", __traits(targetHasFeature, "sse4.1"));
}

def FeatureSSE41   : SubtargetFeature<"sse4.1", "X86SSELevel", "SSE41",
                                      "Enable SSE 4.1 instructions",
                                      [FeatureSSSE3]>;

in
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86.td#L80

So for https://github.com/espressif/llvm-project/blob/xtensa_release_18.1.2/llvm/lib/Target/Xtensa/Xtensa.td#L18

the features will be

  writeln("CPU = ", __traits(targetCPU)); // prints e.g. `esp32s2`
 writeln("Has 'density' = ", __traits(targetHasFeature, "density"));
 writeln("Has 'fp' = ", __traits(targetHasFeature, "fp"));
// ditto for "windowed", "bool", etc.

[TurkeyMan]

I suspect that the different subtarget features will be handled by __traits(targetHasFeature, ...) and the different CPU variants will be handled by __traits(getTargetCPU) (which will return e.g. "esp8266" or "esp32s3")

Yes, this sounds perfect to me!