[Xtensa 4/10] Add basic *td files with Xtensa architecture description.

[andreisfr]

Summary

Add initial Xtensa.td file with target machine description. Add XtensaInstrInfo.td,
currently describe just susbet of Core Instructions like ALU, Processor control,
memory barrier and some move instructions. Add descriptions of the instructions
formats(XtensaInstrInfo.td) and some immediate instruction operands(XtensaOperands.td).
Add General Registers and Special Registers classes.

[arsenm]

llvm/lib/Target/Xtensa/XtensaRegisterInfo.td

41–46

Usually the register names and corresponding generated enums are capitalized

[ivanbaev]

Where is the Xtensa instruction set architecture (ISA) document on which this patch is based on?

[andreisfr]

Register names are capitalized.

[andreisfr]

As for Xtensa instruction set architecture (ISA) document , currently public ISA description mainly available in opensource projects like gcc/qemu/binutils:
https://github.com/gcc-mirror/gcc/tree/master/gcc/config/xtensa
https://github.com/qemu/qemu/blob/master/target/xtensa/translate.c
https://github.com/bminor/binutils-gdb/blob/master/bfd/xtensa-modules.c

[arsenm]

I don’t think I saw an RFC for this target? Was there one I missed?

[andreisfr]

I sent RFC to LLVM community on 6 March http://lists.llvm.org/pipermail/llvm-dev/2019-March/130796.html

[lebedev.ri]

In D64830#1609369, @andreisfr wrote:

As for Xtensa instruction set architecture (ISA) document , currently public ISA description mainly available in opensource projects like gcc/qemu/binutils:
https://github.com/gcc-mirror/gcc/tree/master/gcc/config/xtensa
https://github.com/qemu/qemu/blob/master/target/xtensa/translate.c
https://github.com/bminor/binutils-gdb/blob/master/bfd/xtensa-modules.c

So the only documentation is the existing implementations?
To me personally that does not sound like there is documentation..

[jyknight]

Doing a websearch for "xtensa isa", I do see that documentation does seem to exist: https://github.com/eerimoq/hardware-reference/blob/master/esp32/xtensa%20Instruction%20Set%20Architecture%20(ISA)%20Reference%20Manual.pdf.

It would sure be nice if it was hosted in a more official location, though.

[aykevl]

I do not think there is a reason why the Xtensa architecture shouldn't be included in LLVM. As a comparison, there is also the proprietary (Google) Lanai architecture which was added at a time when there was little public information on it and to this time nobody can actually buy Lanai hardware (there is only a simulator). As a comparison, Xtensa has easy to get hardware (in the form of the ESP8266/ESP32) and is already supported in GCC/binutils.

Looking back at the email thread, there were very few responses. I wonder what should be done next?
Tagging Chris just in case: @lattner

[jyknight]

In D64830#1634592, @aykevl wrote:

I do not think there is a reason why the Xtensa architecture shouldn't be included in LLVM. As a comparison, there is also the proprietary (Google) Lanai architecture which was added at a time when there was little public information on it and to this time nobody can actually buy Lanai hardware (there is only a simulator). As a comparison, Xtensa has easy to get hardware (in the form of the ESP8266/ESP32) and is already supported in GCC/binutils.

I'd note that Lanai did publish a set of ISA docs as part of upstreaming the llvm backend.

Having something like that perhaps doesn't need to be a hard-blocker, but I'd love to see a real response from the xtensa folks, since AFAICT it looks as if like there *IS* ISA documentation, just perhaps not -- officially -- publicly available. It would make things much easier to understand if xtensa published what they had. Without that, nobody else can really review or understand the backend.

[jyknight]

@andreisfr : Ping?

[andreisfr]

I'd note that Lanai did publish a set of ISA docs as part of upstreaming the llvm backend.

Having something like that perhaps doesn't need to be a hard-blocker, but I'd love to see a real response from the xtensa folks, since AFAICT it looks as if like there *IS* ISA documentation, just perhaps not -- officially -- publicly available. It would make things much easier to understand if xtensa published what they had. Without that, nobody else can really review or understand the backend.

@jyknight , as I'm understood, Cadence doesn;t want to publish Xtensa ISA. But it seems that documentation from the link that you provided is quite actual, probably it was published when Xtensa was owned by Tensilica. Also, the code can be reviewed by people from companies that use Xtensa IP in their chips.

BTW there is also an ARC backend (from Synopsys), and I have not found any public documentation with ARC ISA, so probably encoding of ARC instructions also could be verified only by Synopsys engineers.

Also we could prepare summary about Xtensa ISA based on public resources like GCC, Binutils, QEMU with quality enough for code review. What do you think?

[jyknight]

In D64830#1736412, @andreisfr wrote:

@jyknight , as I'm understood, Cadence doesn;t want to publish Xtensa ISA. But it seems that documentation from the link that you provided is quite actual, probably it was published when Xtensa was owned by Tensilica. Also, the code can be reviewed by people from companies that use Xtensa IP in their chips.

That seems really silly -- why wouldn't someone want all users of their CPUs to be able to easily access the ISA docs. Oh well.

Anyways, are there some folks who know LLVM and do have access to the official documentation who can help review the patches? (Maybe asking on the mailing list thread would be useful.)

BTW there is also an ARC backend (from Synopsys), and I have not found any public documentation with ARC ISA, so probably encoding of ARC instructions also could be verified only by Synopsys engineers.

Also we could prepare summary about Xtensa ISA based on public resources like GCC, Binutils, QEMU with quality enough for code review. What do you think?

I think a short summary of the general characteristics of the CPU/ISA would be useful. I do not think that it would be a productive use of time to attempt to reverse-engineer/rewrite an entire ISA doc -- having such a reverse-engineered and possibly incorrect or outdated doc might even be worse than not having it. But I do not think lack of public documentation should be a blocker for inclusion, especially if there are folks who do have access to the privately-available documentation who can help review.

[codehippo]

@andreisfr @jyknight @ivanbaev Ping? Are there any news concerning these pull requests?

[jyknight]

In D64830#1813723, @codehippo wrote:

@andreisfr @jyknight @ivanbaev Ping? Are there any news concerning these pull requests?

From my point of view, this is waiting for the submitter to follow up (or someone may take over).

[andreisfr]

@codehippo, @jyknight, @ivanbaev , we still active develop and improve Xtensa backend, for example this is recent version https://github.com/espressif/llvm-project/tree/xtensa_release_9.x currently we maintain mainstream version and we plan to publish one based on release 10. Current review is paused on *.td files with Xtensa ISA description after the question about ISA documentation, we have been tried to find a way how to help reviewers to aprove this code. We interested to integrate Xtensa backend to upstream and make it available to LLVM community, so we are going to prepare Xtensa ISA description based on opensource projects like binutils, gcc etc. It seems to be the only way to continue review process. What do you think?

[andreisfr]

Patch is updated according to latest upstream version. Updated licenses.

[andreisfr]

@jyknight, @ivanbaev , currently is available Xtensa backend based on latest 9.0.1 release https://github.com/espressif/llvm-project/tree/xtensa_release_9.0.1

[aykevl]

@appcs Do you perhaps have access to the ISA documentation so you can review these patches?

[codehippo]

@andreisfr Has any progress been made on the reverse-engineered Xtensa ISA based on the open-source projects like gcc and binutils?

[• philip-peterson]

Not sure how relevant it is, but I found this PDF which seems to be some documentation for the ISA.

https://0x04.net/~mwk/doc/xtensa.pdf

[brainstorm]

Hello LLVM,

I own an Xtensa ISA document from 2015 and I can confirm that the 2010 ISA document linked above (https://0x04.net/~mwk/doc/xtensa.pdf as @philip-peterson points out) is sufficient to proceed with this review since the changes between those two documents are not that substantial on a first pass. So please, could you take that 0x04.net as authoritative source for this review?

I'd be happy to help review corner cases as they pop up if need be, @ivanbaev @jyknight.

Please bear with me LLVM maintainers since I've never upstreamed a compiler backend, but is there any other document than https://www.llvm.org/docs/WritingAnLLVMBackend.html which outlines the comformance testing required to get this xtensa work in-tree? I would like to see this backend supported in LLVM after all the effort that @andreisfr and others have put into this.

[tonic]

There is also this document: https://llvm.org/docs/DeveloperPolicy.html#adding-a-new-target

[tstellar]

@andreisfr I don't seen any major issues being raised with this backend. It would be great if there was a public official ISA document, but I don't think the lack of one is a blocker. Please make a last check of the reviews in phabricato to see if there are any outstanding issues. Then, I would recommend you take a look at the documentation @tonic posted. Specifically the 5 bullet points under the "The basic rules for a back-end to be upstreamed in experimental mode are:" header. If you think you meet those requirements, please re-send the RFC to the list, so we can discuss getting this added.

[andreisfr]

@brainstorm , @tonic , @tstellar , thank you very much for your help!

I support and improve Xtensa backend now, current version of the backend is rebased on release 11.0.0 https://github.com/espressif/llvm-project/tree/xtensa_release_11.0.0 .

@tstellar , so I can just update these 10 patches according to latest changes in LLVM, add myself as code owner in the first patch and send patches again to list (I will recheck outstanding issues)?

[tstellar]

In D64830#2518675, @andreisfr wrote:

@brainstorm , @tonic , @tstellar , thank you very much for your help!

I support and improve Xtensa backend now, current version of the backend is rebased on release 11.0.0 https://github.com/espressif/llvm-project/tree/xtensa_release_11.0.0 .

@tstellar , so I can just update these 10 patches according to latest changes in LLVM, add myself as code owner in the first patch and send patches again to list (I will recheck outstanding issues)?

@andreisfr Yes, that sounds good.

[aykevl]

@andreisfr any update on this?

It would be great if you could update these patches and send a new RFC to llvm-dev, like you did here: https://lists.llvm.org/pipermail/llvm-dev/2019-March/130796.html

[aykevl]

Also, there is an emulator here: https://github.com/espressif/qemu/wiki
I have successfully used it in the past. Noting it here as it can make backend review/development easier for those who don't have the hardware.

[andreisfr]

@aykevl , I prepared new version of patches and I will update them in 1 day.

[andreisfr]

Patch is updated according to LLVM upstream version and latest Xtensa backend version.

[aykevl]

@andreisfr awesome! Thanks a lot!

Can you please also write a new RFC and send it to llvm-dev like @tstellar proposed? An RFC is the next step in getting this backend accepted.

In D64830#2514379, @tstellar wrote:

If you think you meet those requirements, please re-send the RFC to the list, so we can discuss getting this added.

[craig.topper]

llvm/lib/Target/Xtensa/Xtensa.td

2

Please limit line length to 80 characters

llvm/lib/Target/Xtensa/XtensaInstrFormats.td

2

Please limit line length to 80 characters

15

I think the prevailing style in LLVM has the open curly brace at the end of the previous line.

32

It might just be me, but I find this lining the XtensaInst up with template parameters hard to read. I think a common style is to put at the start of the line with only a small indentation. For example

class PseudoI<dag oops, dag iops, list<dag> pattern>                                                                                                                                                                                                                                   
  : X86Inst<0, Pseudo, NoImm, oops, iops, ""> {                                                                                                                                                                                                                                        
  let Pattern = pattern;                                                                                                                                                                                                                                                               
}

llvm/lib/Target/Xtensa/XtensaOperands.td

2

This line seems shorter than 80 characters.

[andreisfr]

Correct instruction descriptions, format descriptions and instruction operands according to common style for *.td files.

[andreisfr]

llvm/lib/Target/Xtensa/Xtensa.td

2

Corrected

llvm/lib/Target/Xtensa/XtensaInstrFormats.td

2

Corrected

15

Corrected for instruction descriptions, format descriptions and instruction operands.

32

@craig.topper , I corrected instruction formats and instruction descriptions, do you think that this code now in common style or it must be corrected bit more?

llvm/lib/Target/Xtensa/XtensaOperands.td

2

Corrected

[andreisfr]

@craig.topper , thank you very much for comments!

[craig.topper]

llvm/lib/Target/Xtensa/XtensaInstrFormats.td

32

I think this looks better. Unfortunately, we don't have a formatting tool for tablegen and no rules are written down. I think this is good enough.

167

Drop the second blank line?

llvm/lib/Target/Xtensa/XtensaRegisterInfo.td

31

This is overindented relative to the style of the rest of the file.

[andreisfr]

Corrected indentation, removed blank line

llvm/lib/Target/Xtensa/XtensaInstrFormats.td

167

Corrected

llvm/lib/Target/Xtensa/XtensaRegisterInfo.td

31

Corrected

[kairoswater-jason]

Who is needed to review and approve this patch?

[andreisfr]

Patch is updated according to LLVM upstream version.

[luojia]

What's the current state of this patch? :)

[andreisfr]

In D64830#3474080, @luojia wrote:

What's the current state of this patch? :)

HI @luojia, thank you for your interest to the Xtensa backend.

Currently, probably all suggestions in comments for this patch were implemented. If you can help with further reviewing or approving this patch that would be great.
Brief status of the whole series of the Xtensa backend patches :

1. All 10 patches are updated according to the latest upstream changes . Patches 1-3 are approved.
2. We have submitted an RFC to the mailing list https://lists.llvm.org/pipermail/llvm-dev/2021-March/149090.html .
3. We have written the ISA documentation https://github.com/espressif/xtensa-isa-doc .
4. Also we have a branch on Github with patches rebased to llvm-project main branch https://github.com/espressif/llvm-project/tree/main_xtensa .

[saugustine]

I have access to an up-to-date copy of the isa book and can review these for technical correctness. I'm less familiar with style issues.

I have checked the bitfields, encodings, and field names. They are all correct.

Some comments below, especially on the xSYNC instructions. Nothing too serious, but they do have side effects of one form or another. Typically a compiler wouldn't generate them unless as part of a larger hard-coded, unsplittable block, but if they are present, they ought to be correct.

llvm/lib/Target/Xtensa/XtensaInstrFormats.td

53

These fields are reverse order in big endian versions of the core. Is the ESP32 implementation of Xtensa always little endian?

It would be nice to handle both variants, but that isn't a block for this patch.

llvm/lib/Target/Xtensa/XtensaInstrInfo.td

102

This is quite a bit more conservative than necessary. MEMW only serializes memory operations, it is fine to move arithmetic ops across it.

109

This instruction is a superset of MEMW and serializes all externally visible operations.

hasSideEffects is necessary on this one (at least in a base ISA implementation).

116

DSYNC is the least intrusive processor-state sync instruction, used to serialize loads and stores against WSR and XSR instructions that may update the page table.

It could be modeled quite similarly to MEMW, but with a more complete memory-barrier model, it should include side effects.

123

ISYNC synchronizes the instruction fetch unit against updates to the icache. Needs hasSideEffects set.

130

This synchronizes reading register fields out of instructions against WSR and XSR modifying the register window. Needs hasSideEffects set.

137

This is quite similar to RSYNC, but synchronizes the exact read from the register window, rather than the fields out of the instruction. Needs hasSideEffects set.

[andreisfr]

Corrected MEMW, EXTW, DSYNC, ESYNC, ISYNC and RSYNC instruction descriptions

[andreisfr]

@saugustine , thank you very much for your comments!

llvm/lib/Target/Xtensa/XtensaInstrFormats.td

53

Yes, the ESP32 implementation is always little endian, and I didn't observed any public available big endian implementations. So, initial idea was to implement just little endian at first and maybe implement support of the big endian in future.

llvm/lib/Target/Xtensa/XtensaInstrInfo.td

102

Corrected

109

Corrected

116

Corrected

123

Corrected

130

Corrected

137

Corrected

[andreisfr]

@aykevl , @jyknight , @ivanbaev , I have a good news about Xtensa ISA documentation. Cadence makes documentation publicly available https://www.cadence.com/content/dam/cadence-www/global/en_US/documents/tools/ip/tensilica-ip/isa-summary.pdf

[jscott]

What is the current state of this patch? As the Debian maintainer of ath9k_htc, the flagship libre wireless firmware for USB adapters, I eagerly wait for this to be merged so that I may begin exploring using LLVM to build the firmware, which is currently a rather painful process with GCC.

[sstefan1]

Hi everyone. Since this has been accepted for some time now, we're planning to commit this on Monday (December 16th). Please let us know if there is anything else we should address.

[barannikov88]

llvm/lib/Target/Xtensa/XtensaInstrFormats.td

218

• IIRC SoftFail is no longer necessary after this patch (if you don't use this functionality, of course).
• 'field' seems redundant, too (hasn't this keyword been deprecated?).
• Do isCodeGenOnly instructions really need encoding bits?

[andreisfr]

Added fixes according to comments

[andreisfr]

llvm/lib/Target/Xtensa/XtensaInstrFormats.td

218

Thank you for comments, I removed redundant code.

llvm/lib/Target/Xtensa/CMakeLists.txt

 add_llvm_component_group(Xtensa)
 
+set(LLVM_TARGET_DEFINITIONS Xtensa.td)
+
+tablegen(LLVM XtensaGenInstrInfo.inc -gen-instr-info)
+tablegen(LLVM XtensaGenRegisterInfo.inc -gen-register-info)
+
+add_public_tablegen_target(XtensaCommonTableGen)
+
 add_llvm_target(XtensaCodeGen
   XtensaTargetMachine.cpp
 
   LINK_COMPONENTS
   CodeGen
   Core
   Support
   Target
   XtensaInfo
 
   ADD_TO_COMPONENT
   Xtensa
   )
 
 add_subdirectory(MCTargetDesc)
 add_subdirectory(TargetInfo)

llvm/lib/Target/Xtensa/Xtensa.td

+//===- Xtensa.td - Describe the Xtensa Target Machine ------*- tablegen -*-===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+//===----------------------------------------------------------------------===//
+// Target-independent interfaces
+//===----------------------------------------------------------------------===//
+
+include "llvm/Target/Target.td"
+
+//===----------------------------------------------------------------------===//
+// Subtarget Features.
+//===----------------------------------------------------------------------===//
+def FeatureDensity : SubtargetFeature<"density", "HasDensity", "true",
+                    "Enable Density instructions">;
+def HasDensity : Predicate<"Subtarget->hasDensity()">,
+                     AssemblerPredicate<(all_of FeatureDensity)>;
+//===----------------------------------------------------------------------===//
+// Xtensa supported processors.
+//===----------------------------------------------------------------------===//
+class Proc<string Name, list<SubtargetFeature> Features>
+    : Processor<Name, NoItineraries, Features>;
+
+def : Proc<"generic", []>;
+
+//===----------------------------------------------------------------------===//
+// Register File Description
+//===----------------------------------------------------------------------===//
+
+include "XtensaRegisterInfo.td"
+
+//===----------------------------------------------------------------------===//
+// Instruction Descriptions
+//===----------------------------------------------------------------------===//
+
+include "XtensaInstrInfo.td"
+
+def XtensaInstrInfo : InstrInfo;
+
+//===----------------------------------------------------------------------===//
+// Target Declaration
+//===----------------------------------------------------------------------===//
+
+def Xtensa : Target {
+  let InstructionSet = XtensaInstrInfo;
+}

llvm/lib/Target/Xtensa/XtensaInstrFormats.td

+//===- XtensaInstrFormats.td - Xtensa Instruction Formats --*- tablegen -*-===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// Base class for Xtensa 16 & 24 bit Formats
+class XtensaInst<int size, dag outs, dag ins, string asmstr, list<dag> pattern,
+                 InstrItinClass itin = NoItinerary>
+  : Instruction {
+  let Namespace = "Xtensa";
+
+  let Size = size;
+
+  let OutOperandList = outs;
+  let InOperandList  = ins;
+
+  let AsmString   = asmstr;
+  let Pattern     = pattern;
+  let Itinerary   = itin;
+
+}
+
+// Base class for Xtensa 24 bit Format
+class XtensaInst24<dag outs, dag ins, string asmstr, list<dag> pattern,
+                   InstrItinClass itin = NoItinerary>
+  : XtensaInst<3, outs, ins, asmstr, pattern, itin> {
+  field bits<24> Inst;
+  field bits<24> SoftFail = 0;
+}
+
+// Base class for Xtensa 16 bit Format
+class XtensaInst16<dag outs, dag ins, string asmstr, list<dag> pattern,
+                   InstrItinClass itin = NoItinerary>
+  : XtensaInst<2, outs, ins, asmstr, pattern, itin> {
+  field bits<16> Inst;
+  field bits<16> SoftFail = 0;
+  let Predicates = [HasDensity];
+}
+
+class RRR_Inst<bits<4> op0, bits<4> op1, bits<4> op2, dag outs, dag ins,
+               string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst24<outs, ins, asmstr, pattern, itin> {
+  bits<4> r;
+  bits<4> s;
+  bits<4> t;
+
+  let Inst{23-20} = op2;
+  let Inst{19-16} = op1;
+  let Inst{15-12} = r;
+  let Inst{11-8} = s;
+  let Inst{7-4} = t;
+  let Inst{3-0} = op0;
+}
+
+class RRI4_Inst<bits<4> op0, bits<4> op1, dag outs, dag ins,
+                string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst24<outs, ins, asmstr, pattern, itin> {
+  bits<4> r;
+  bits<4> s;
+  bits<4> t;
+  bits<4> imm4;
+
+  let Inst{23-20} = imm4;
+  let Inst{19-16} = op1;
+  let Inst{15-12} = r;
+  let Inst{11-8} = s;
+  let Inst{7-4} = t;
+  let Inst{3-0} = op0;
+}
+
+class RRI8_Inst<bits<4> op0, dag outs, dag ins,
+                string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst24<outs, ins, asmstr, pattern, itin> {
+  bits<4> r;
+  bits<4> s;
+  bits<4> t;
+  bits<8> imm8;
+
+  let Inst{23-16} = imm8;
+  let Inst{15-12} = r;
+  let Inst{11-8} = s;
+  let Inst{7-4} = t;
+  let Inst{3-0} = op0;
+}
+
+class RI16_Inst<bits<4> op0, dag outs, dag ins,
+                string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst24<outs, ins, asmstr, pattern, itin> {
+  bits<4> t;
+  bits<16> imm16;
+
+  let Inst{23-8} = imm16;
+  let Inst{7-4} = t;
+  let Inst{3-0} = op0;
+}
+
+class RSR_Inst<bits<4> op0, bits<4> op1, bits<4> op2, dag outs, dag ins,
+               string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst24<outs, ins, asmstr, pattern, itin> {
+  bits<8> sr;
+  bits<4> t;
+
+  let Inst{23-20} = op2;
+  let Inst{19-16} = op1;
+  let Inst{15-8} = sr;
+  let Inst{7-4} = t;
+  let Inst{3-0} = op0;
+}
+
+class CALL_Inst<bits<4> op0, dag outs, dag ins,
+                string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst24<outs, ins, asmstr, pattern, itin> {
+  bits<18> offset;
+  bits<2> n;
+
+  let Inst{23-6} = offset;
+  let Inst{5-4} = n;
+  let Inst{3-0} = op0;
+}
+
+class CALLX_Inst<bits<4> op0, bits<4> op1, bits<4> op2, dag outs, dag ins,
+                 string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst24<outs, ins, asmstr, pattern, itin> {
+  bits<4> r;
+  bits<4> s;
+  bits<2> m;
+  bits<2> n;
+
+  let Inst{23-20} = op2;
+  let Inst{19-16} = op1;
+  let Inst{15-12} = r;
+  let Inst{11-8} = s;
+  let Inst{7-6} = m;
+  let Inst{5-4} = n;
+  let Inst{3-0} = op0;
+}
+
+class BRI8_Inst<bits<4> op0, dag outs, dag ins,
+                string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst24<outs, ins, asmstr, pattern, itin> {
+  bits<8> imm8;
+  bits<4> r;
+  bits<4> s;
+  bits<2> m;
+  bits<2> n;
+
+  let Inst{23-16} = imm8;
+  let Inst{15-12} = r;
+  let Inst{11-8} = s;
+  let Inst{7-6} = m;
+  let Inst{5-4} = n;
+  let Inst{3-0} = op0;
+}
+
+class BRI12_Inst<bits<4> op0, bits<2> n, bits<2> m, dag outs, dag ins,
+                 string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst24<outs, ins, asmstr, pattern, itin> {
+  bits<12> imm12;
+  bits<4> s;
+
+  let Inst{23-12} = imm12;
+  let Inst{11-8} = s;
+  let Inst{7-6} = m;
+  let Inst{5-4} = n;
+  let Inst{3-0} = op0;
+}
+
+class RRRN_Inst<bits<4> op0, dag outs, dag ins,
+                string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst16<outs, ins, asmstr, pattern, itin> {
+  bits<4> r;
+  bits<4> s;
+  bits<4> t;
+
+  let Inst{15-12} = r;
+  let Inst{11-8} = s;
+  let Inst{7-4} = t;
+  let Inst{3-0} = op0;
+}
+
+class RI7_Inst<bits<4> op0, bits<1> i, dag outs, dag ins,
+               string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst16<outs, ins, asmstr, pattern, itin> {
+  bits<7> imm7;
+  bits<4> s;
+
+  let Inst{15-12} = imm7{3-0};
+  let Inst{11-8} = s;
+  let Inst{7} = i;
+  let Inst{6-4} = imm7{6-4};
+  let Inst{3-0} = op0;
+}
+
+class RI6_Inst<bits<4> op0, bits<1> i,  bits<1> z, dag outs, dag ins,
+               string asmstr, list<dag> pattern, InstrItinClass itin = NoItinerary>
+  : XtensaInst16<outs, ins, asmstr, pattern, itin> {
+  bits<6> imm6;
+  bits<4> s;
+
+  let Inst{15-12} = imm6{3-0};
+  let Inst{11-8} = s;
+  let Inst{7} = i;
+  let Inst{6} = z;
+  let Inst{5-4} = imm6{5-4};
+  let Inst{3-0} = op0;
+}
+
+// Pseudo instructions
+class Pseudo<dag outs, dag ins, string asmstr, list<dag> pattern>
+  : XtensaInst<2, outs, ins, asmstr, pattern> {
+  let isPseudo = 1;
+  let isCodeGenOnly = 1;
+}

llvm/lib/Target/Xtensa/XtensaInstrInfo.td

+//===- XtensaInstrInfo.td - Target Description for Xtensa -*- tablegen -*--===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file describes the Xtensa instructions in TableGen format.
+//
+//===----------------------------------------------------------------------===//
+
+include "XtensaInstrFormats.td"
+include "XtensaOperands.td"
+
+//===----------------------------------------------------------------------===//
+// Arithmetic & Logical instructions
+//===----------------------------------------------------------------------===//
+
+class ArithLogic_RRR<bits<4> oper2, bits<4> oper1, string instrAsm,
+      SDPatternOperator opNode, bit isComm = 0>
+  : RRR_Inst<0x00, oper1, oper2, (outs AR:$r), (ins AR:$s, AR:$t),
+             instrAsm#"\t$r, $s, $t",
+            [(set AR:$r, (opNode AR:$s, AR:$t))]> {
+  let isCommutable = isComm;
+  let isReMaterializable = 0;
+}
+
+def ADD : ArithLogic_RRR<0x08, 0x00, "add", add, 1>;
+def SUB : ArithLogic_RRR<0x0C, 0x00, "sub", sub>;
+def AND : ArithLogic_RRR<0x01, 0x00, "and", and, 1>;
+def OR  : ArithLogic_RRR<0x02, 0x00, "or", or, 1>;
+def XOR : ArithLogic_RRR<0x03, 0x00, "xor", xor, 1>;
+
+class ADDX<bits<4> oper, string instrAsm, list<dag> pattern>
+  : RRR_Inst<0x00, 0x00, oper, (outs AR:$r), (ins AR:$s, AR:$t),
+             instrAsm#"\t$r, $s, $t", pattern>;
+
+def ADDX2 : ADDX<0x09, "addx2", [(set AR:$r, (add AR:$t, (shl AR:$s, (i32 1))))]>;
+def ADDX4 : ADDX<0x0A, "addx4", [(set AR:$r, (add AR:$t, (shl AR:$s, (i32 2))))]>;
+def ADDX8 : ADDX<0x0B, "addx8", [(set AR:$r, (add AR:$t, (shl AR:$s, (i32 3))))]>;
+
+class SUBX<bits<4> oper, string instrAsm, list<dag> pattern>
+  : RRR_Inst<0x00, 0x00, oper, (outs AR:$r), (ins AR:$s, AR:$t),
+             instrAsm#"\t$r, $s, $t", pattern>;
+
+def SUBX2 : SUBX<0x0D, "subx2", [(set AR:$r, (sub (shl AR:$s, (i32 1)), AR:$t))]>;
+def SUBX4 : SUBX<0x0E, "subx4", [(set AR:$r, (sub (shl AR:$s, (i32 2)), AR:$t))]>;
+def SUBX8 : SUBX<0x0F, "subx8", [(set AR:$r, (sub (shl AR:$s, (i32 3)), AR:$t))]>;
+
+def ABS : RRR_Inst<0x00, 0x00, 0x06, (outs AR:$r), (ins AR:$t),
+                  "abs\t$r, $t", []> {
+  let s = 0x1;
+}
+
+def ADDI : RRI8_Inst<0x02, (outs AR:$t), (ins AR:$s, imm8:$imm8),
+                    "addi\t$t, $s, $imm8",
+                    [(set AR:$t, (add AR:$s, imm8:$imm8))]> {
+  let r = 0x0C;
+}
+
+def ADDMI : RRI8_Inst<0x02, (outs AR:$t), (ins AR:$s, imm8_sh8:$imm_sh8),
+                     "addmi\t$t, $s, $imm_sh8",
+                     [(set AR:$t, (add AR:$s, imm8_sh8:$imm_sh8))]> {
+  bits<16> imm_sh8;
+
+  let r = 0x0D;
+  let imm8 = imm_sh8{15-8};
+}
+
+def NEG : RRR_Inst<0x00, 0x00, 0x06, (outs AR:$r), (ins AR:$t),
+                  "neg\t$r, $t",
+                  [(set AR:$r, (ineg AR:$t))]> {
+  let s = 0x00;
+}
+
+//===----------------------------------------------------------------------===//
+// Move instructions
+//===----------------------------------------------------------------------===//
+
+// Conditional move
+def MOVEQZ : RRR_Inst<0x00, 0x03, 0x08, (outs AR:$r), (ins AR:$s, AR:$t),
+                     "moveqz\t$r, $s, $t", []>;
+def MOVNEZ : RRR_Inst<0x00, 0x03, 0x09, (outs AR:$r), (ins AR:$s, AR:$t),
+                     "movnez\t$r, $s, $t", []>;
+def MOVLTZ : RRR_Inst<0x00, 0x03, 0x0A, (outs AR:$r), (ins AR:$s, AR:$t),
+                     "movltz\t$r, $s, $t", []>;
+def MOVGEZ : RRR_Inst<0x00, 0x03, 0x0B, (outs AR:$r), (ins AR:$s, AR:$t),
+                     "movgez\t$r, $s, $t", []>;
+
+//===----------------------------------------------------------------------===//
+// Mem barrier instructions
+//===----------------------------------------------------------------------===//
+def MEMW :  RRR_Inst<0x00, 0x00, 0x00, (outs), (ins),
+                    "memw", []> {
+  let r = 0x2;
+  let t = 0x0c;
+  let s = 0x0;
+}
+
+def EXTW : RRR_Inst<0x00, 0x00, 0x00, (outs), (ins),
+                   "extw", []> {
+  let r = 0x2;
+  let s = 0x0;
+  let t = 0xd;
+  let hasSideEffects = 1;
+}
+
+//===----------------------------------------------------------------------===//
+// Processor control instructions
+//===----------------------------------------------------------------------===//
+
+def DSYNC : RRR_Inst<0x00, 0x00, 0x00, (outs), (ins),
+                    "dsync", []> {
+  let r = 0x2;
+  let s = 0x0;
+  let t = 0x3;
+  let hasSideEffects = 1;
+}
+
+def ISYNC : RRR_Inst<0x00, 0x00, 0x00, (outs), (ins),
+                    "isync", []> {
+  let r = 0x2;
+  let s = 0x0;
+  let t = 0x0;
+  let hasSideEffects = 1;
+}
+
+def RSYNC : RRR_Inst<0x00, 0x00, 0x00, (outs), (ins),
+                    "rsync", []> {
+  let r = 0x2;
+  let s = 0x0;
+  let t = 0x1;
+  let hasSideEffects = 1;
+}
+
+def ESYNC : RRR_Inst<0x00, 0x00, 0x00, (outs), (ins),
+                    "esync", []> {
+  let r = 0x2;
+  let s = 0x0;
+  let t = 0x2;
+  let hasSideEffects = 1;
+}
+
+def NOP : RRR_Inst<0x00, 0x00, 0x00, (outs), (ins),
+                  "nop", []> {
+  let r = 0x02;
+  let s = 0x00;
+  let t = 0x0f;
+}

llvm/lib/Target/Xtensa/XtensaOperands.td

+//===- XtensaOperands.td - Xtensa instruction operands -------*- tblgen-*--===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// Immediate operands with a shared generic render method.
+class ImmAsmOperand<string name> : AsmOperandClass {
+  let Name = name;
+  let RenderMethod = "addImmOperands";
+  let DiagnosticType = !strconcat("Invalid", name);
+}
+
+class Immediate<ValueType vt, code pred, string asmop>
+  : Operand<vt>, ImmLeaf<vt, pred> {
+  let PrintMethod = "print"#asmop;
+  let ParserMatchClass = !cast<AsmOperandClass>(asmop);
+}
+
+// imm8 predicate - Immediate in the range [-128,127]
+def Imm8_AsmOperand : ImmAsmOperand<"Imm8">;
+def imm8 : Immediate<i32, [{ return Imm >= -128 && Imm <= 127; }], "Imm8_AsmOperand">;
+
+// imm8_sh8 predicate - Immediate in the range [-32768,32512] with (bits[7-0] == 0)
+// imm8 value left shifted by 8 bits
+def Imm8_sh8_AsmOperand : ImmAsmOperand<"Imm8_sh8">;
+def imm8_sh8 : Immediate<i32, [{ return Imm >= -32768 && Imm <= 32512 && ((Imm & 0xFF) == 0); }],
+                        "Imm8_sh8_AsmOperand">;

llvm/lib/Target/Xtensa/XtensaRegisterInfo.td

+//===- XtensaRegisterInfo.td - Xtensa Register defs --------*- tablegen -*-===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+//===----------------------------------------------------------------------===//
+// Class definitions.
+//===----------------------------------------------------------------------===//
+
+class XtensaReg<string n> : Register<n> {
+  let Namespace = "Xtensa";
+}
+
+class XtensaRegWithSubRegs<string n, list<Register> subregs>
+  : RegisterWithSubRegs<n, subregs> {
+  let Namespace = "Xtensa";
+}
+
+//===----------------------------------------------------------------------===//
+// General-purpose registers
+//===----------------------------------------------------------------------===//
+
+// Xtensa general purpose regs
+class ARReg<bits<4> num, string n, list<string> alt = []> : XtensaReg<n> {
+  let HWEncoding{3-0} = num;
+  let AltNames = alt;
+}
+
+// Return Address
+def A0 : ARReg<0, "a0">, DwarfRegNum<[0]>;
+
+// Stack Pointer (callee-saved)
+def SP : ARReg<1, "a1", ["sp"]>, DwarfRegNum<[1]>;
+
+// Function Arguments
+def A2 : ARReg<2, "a2">, DwarfRegNum<[2]>;
+def A3 : ARReg<3, "a3">, DwarfRegNum<[3]>;
+def A4 : ARReg<4, "a4">, DwarfRegNum<[4]>;
+def A5 : ARReg<5, "a5">, DwarfRegNum<[5]>;
+def A6 : ARReg<6, "a6">, DwarfRegNum<[6]>;
+def A7 : ARReg<7, "a7">, DwarfRegNum<[7]>;
+
+// Static Chain
+def A8 : ARReg<8, "a8">, DwarfRegNum<[8]>;
+
+def A9 : ARReg<9, "a9">, DwarfRegNum<[9]>;
+def A10 : ARReg<10, "a10">, DwarfRegNum<[10]>;
+def A11 : ARReg<11, "a11">, DwarfRegNum<[11]>;
+
+// Callee-saved
+def A12 : ARReg<12, "a12">, DwarfRegNum<[12]>;
+def A13 : ARReg<13, "a13">, DwarfRegNum<[13]>;
+def A14 : ARReg<14, "a14">, DwarfRegNum<[14]>;
+
+// Stack-Frame Pointer (optional) - Callee-Saved
+def A15 : ARReg<15, "a15">, DwarfRegNum<[15]>;
+
+// Register class with allocation order
+def AR : RegisterClass<"Xtensa", [i32], 32, (add
+  A8, A9, A10, A11, A12, A13, A14, A15,
+  A7, A6, A5, A4, A3, A2, A0, SP)>;
+//===----------------------------------------------------------------------===//
+// Special-purpose registers
+//===----------------------------------------------------------------------===//
+class SRReg<bits<8> num, string n, list<string> alt = []> : XtensaReg<n> {
+  let HWEncoding{7-0} = num;
+  let AltNames = alt;
+}
+
+// Shift Amount Register
+def SAR : SRReg<3, "sar", ["SAR","3"]>;
+
+def SR :  RegisterClass<"Xtensa", [i32], 32, (add SAR)>;