[TableGen][DirectX] Add tableGen backend to generate DXIL operation for DirectX backend.

A new tableGen backend gen-dxil-enum is added to generate enum for DXIL operation and operation class.

A new

[TableGen][DirectX] Add tableGen backend to generate DXIL operation for DirectX backend.

A new tableGen backend gen-dxil-enum is added to generate enum for DXIL operation and operation class.

A new file "DXILConstants.inc" will be generated when build DirectX target which include the enums.

More tableGen backends will be added to replace manually written table in DirectX backend.
The unused fields in dxil_inst will be used in future PR.

Reviewed By: bogner

Differential Revision: https://reviews.llvm.org/D125435

show more ...

[TableGen] Remove code beads

Code beads is useless since the only user, M68k, has moved on to
a new encoding/decoding infrastructure.

Reviewed By: myhsu

Differential Revision: https://reviews.llvm

[TableGen] Remove code beads

Code beads is useless since the only user, M68k, has moved on to
a new encoding/decoding infrastructure.

Reviewed By: myhsu

Differential Revision: https://reviews.llvm.org/D126349

show more ...

Revert "[TableGen] Remove code beads"

It is breaking the build with:

/build/llvm-toolchain-snapshot-15~++20220524114008+96323c9f4c10/llvm/lib/Target/M68k/MCTargetDesc/M68kMCCodeEmitter.cpp:478:10:

Revert "[TableGen] Remove code beads"

It is breaking the build with:

/build/llvm-toolchain-snapshot-15~++20220524114008+96323c9f4c10/llvm/lib/Target/M68k/MCTargetDesc/M68kMCCodeEmitter.cpp:478:10: fatal error: 'M68kGenMCCodeBeads.inc' file not found
^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Remove the #include causes:
error: undefined reference to 'llvm::M68k::getMCInstrBeads(unsigned int)'

This reverts commit f50be3d21808ae113c40a68a9ac6581f203d92d2.

show more ...

[TableGen] Remove code beads

Code beads is useless since the only user, M68k, has moved on to
a new encoding/decoding infrastructure.

[TableGen] X86 mnemonic tables backend

Add tablegen backend that generates X86 mnemonic-based opcode groupings, e.g.
`isADD`, `isTEST`, etc.

Addresses https://lists.llvm.org/pipermail/llvm-dev/2022

[TableGen] X86 mnemonic tables backend

Add tablegen backend that generates X86 mnemonic-based opcode groupings, e.g.
`isADD`, `isTEST`, etc.

Addresses https://lists.llvm.org/pipermail/llvm-dev/2022-January/154526.html

Reviewed By: skan

Differential Revision: https://reviews.llvm.org/D121571

show more ...

[openacc][openmp] Reduce number of generated file and prefer inclusion of .inc

Follow up from D92955 and D83636. This patch makes the base cpp files
OMP.cpp and ACC.cpp normal files and they now inc

[openacc][openmp] Reduce number of generated file and prefer inclusion of .inc

Follow up from D92955 and D83636. This patch makes the base cpp files
OMP.cpp and ACC.cpp normal files and they now include the XXX.inc file
generated by tablegen. This reduces the number of file generated by the
DirectiveEmitter backend and makes it closer to the proposal in D83636.

Reviewed By: Meinersbur

Differential Revision: https://reviews.llvm.org/D93560

show more ...

[M68k][TableGen](1/8) TableGen related changes

- Add a new TableGen backend: CodeBeads
- Add support to generate logical operand information

For the first item, it is currently a workaround of M6

[M68k][TableGen](1/8) TableGen related changes

- Add a new TableGen backend: CodeBeads
- Add support to generate logical operand information

For the first item, it is currently a workaround of M68k's (complex)
instruction encoding. A typical architecture, especially CISC one like
X86, normally uses `MCInstrDesc::TSFlags` to carry instruction encoding
info. However, at the early days of M68k backend development, we found
it difficult to fit every possible encoding into the 64-bit
`MCInstrDesc::TSFlags`. Therefore CodeBeads was invented to provide
an alternative, arbitrary length container for instruciton encoding
info. However, in the long term we incline not to use a new TG
backend for less common pattern like what we encountered in M68k. A bug
has been created to host to discussion on migrating from CodeBeads to
more concise solution: https://bugs.llvm.org/show_bug.cgi?id=48792

The second item was also served for similar purpose. It created utility
functions that tell you the index of a `MachineOperand` in a
`MachineInst` given a logical operand index. In normal cases a logical
operand is the same as `MachineOperand`, but for operands using complex
addressing mode a logical operand might be consisting of multiple
`MachineOperand`. The TableGen-ed `getLogicalOperandIdx`, for instance,
can give you the mapping between these two concepts. Nevertheless, we
hope to remove this feature in the future if possible. Since it's not
really useful for the targets supported by LLVM now either.

Authors: myhsu, m4yers, glaubitz

Differential Revision: https://reviews.llvm.org/D88385

show more ...

[flang][openmp] Check clauses allowed semantic with tablegen generated map

Summary:
This patch is enabling the generation of clauses enum sets for semantics check in Flang through
tablegen. Enum set

[flang][openmp] Check clauses allowed semantic with tablegen generated map

Summary:
This patch is enabling the generation of clauses enum sets for semantics check in Flang through
tablegen. Enum sets and directive - sets map is generated by the new tablegen infrsatructure for OpenMP
and other directive languages.
The semantic checks for OpenMP are modified to use this newly generated map.

Reviewers: DavidTruby, sscalpone, kiranchandramohan, ichoyjx, jdoerfert

Reviewed By: DavidTruby, ichoyjx

Subscribers: mgorny, yaxunl, hiraditya, guansong, sstefan1, aaron.ballman, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D83326

show more ...

[openmp] Move Directive and Clause helper function to tablegen

Summary:
Follow up to D81736. Move getOpenMPDirectiveKind, getOpenMPClauseKind, getOpenMPDirectiveName and
getOpenMPClauseName to the n

[openmp] Move Directive and Clause helper function to tablegen

Summary:
Follow up to D81736. Move getOpenMPDirectiveKind, getOpenMPClauseKind, getOpenMPDirectiveName and
getOpenMPClauseName to the new tablegen code generation. The code is generated in a new file named OMP.cpp.inc

Reviewers: jdoerfert, jdenny, thakis

Reviewed By: jdoerfert, jdenny

Subscribers: mgorny, yaxunl, hiraditya, guansong, sstefan1, llvm-commits, thakis

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D82405

show more ...

[openmp] Base of tablegen generated OpenMP common declaration

Summary:
As discussed previously when landing patch for OpenMP in Flang, the idea is
to share common part of the OpenMP declaration betw

[openmp] Base of tablegen generated OpenMP common declaration

Summary:
As discussed previously when landing patch for OpenMP in Flang, the idea is
to share common part of the OpenMP declaration between the different Frontend.
While doing this it was thought that moving to tablegen instead of Macros will also
give a cleaner and more powerful way of generating these declaration.
This first part of a future series of patches is setting up the base .td file for
DirectiveLanguage as well as the OpenMP version of it. The base file is meant to
be used by other directive language such as OpenACC.
In this first patch, the Directive and Clause enums are generated with tablegen
instead of the macros on OMPConstants.h. The next pacth will extend this
to other enum and move the Flang frontend to use it.

Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp

Reviewed By: jdoerfert, jdenny

Subscribers: arphaman, martong, cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits

Tags: #llvm, #openmp, #clang

Differential Revision: https://reviews.llvm.org/D81736

show more ...

Revert commit 9e52530 because of dependencies issue

This reverts commit 9e525309fb3cbea4ab341b54d127d97831962285.

[openmp] Base of tablegen generated OpenMP common declaration

Summary:
As discussed previously when landing patch for OpenMP in Flang, the idea is
to share common part of the OpenMP declaration betw

[openmp] Base of tablegen generated OpenMP common declaration

Summary:
As discussed previously when landing patch for OpenMP in Flang, the idea is
to share common part of the OpenMP declaration between the different Frontend.
While doing this it was thought that moving to tablegen instead of Macros will also
give a cleaner and more powerful way of generating these declaration.
This first part of a future series of patches is setting up the base .td file for
DirectiveLanguage as well as the OpenMP version of it. The base file is meant to
be used by other directive language such as OpenACC.
In this first patch, the Directive and Clause enums are generated with tablegen
instead of the macros on OMPConstants.h. The next pacth will extend this
to other enum and move the Flang frontend to use it.

Reviewers: jdoerfert, DavidTruby, fghanim, ABataev, jdenny, hfinkel, jhuber6, kiranchandramohan, kiranktp

Reviewed By: jdoerfert, jdenny

Subscribers: cfe-commits, mgorny, yaxunl, hiraditya, guansong, jfb, sstefan1, aaron.ballman, llvm-commits

Tags: #llvm, #openmp, #clang

Differential Revision: https://reviews.llvm.org/D81736

show more ...

[TableGen] Remove unused target intrinsic generation logic

AMDGPU was the last in tree target to use this tablegen mode. I plan to
split up the global intrinsic enum similar to the way that clang
di

[TableGen] Remove unused target intrinsic generation logic

AMDGPU was the last in tree target to use this tablegen mode. I plan to
split up the global intrinsic enum similar to the way that clang
diagnostics are split up today. I don't plan to build on this mode.

Reviewers: arsenm, echristo, efriedma

Reviewed By: echristo

Differential Revision: https://reviews.llvm.org/D71318

show more ...

[TableGen] Add backend to generate command guide for tools using libOption.

For lldb and dsymutil, the command guide is essentially a copy of its
help output generated by libOption. Making sure the

[TableGen] Add backend to generate command guide for tools using libOption.

For lldb and dsymutil, the command guide is essentially a copy of its
help output generated by libOption. Making sure the two stay in sync is
tedious and error prone. Given that we already generate the help from a
tablegen file, we might as well generate the RST as well.

This adds a tablegen backend for generating Sphinx/RST command guides
from the tablegen file.

Differential revision: https://reviews.llvm.org/D70610

show more ...

[TableGen] Introduce a generic automaton (DFA) backend

Summary:
This patch introduces -gen-automata, a backend for generating deterministic finite-state automata.

DFAs are already generated by the

[TableGen] Introduce a generic automaton (DFA) backend

Summary:
This patch introduces -gen-automata, a backend for generating deterministic finite-state automata.

DFAs are already generated by the -gen-dfa-packetizer backend. This backend is more generic and will
hopefully be used to implement the DFA generation (and determinization) for the packetizer in the
future.

This backend allows not only generation of a DFA from an NFA (nondeterministic finite-state
automaton), it also emits sidetables that allow a path through the DFA under a sequence of inputs to
be analyzed, and the equivalent set of all possible NFA transitions extracted.

This allows a user to not just answer "can my problem be solved?" but also "what is the
solution?". Clearly this analysis is more expensive than just playing a DFA forwards so is
opt-in. The DFAPacketizer has this behaviour already but this is a more compact and generic
representation.

Examples are bundled in unittests/TableGen/Automata.td. Some are trivial, but the BinPacking example
is a stripped-down version of the original target problem I set out to solve, where we pack values
(actually immediates) into bins (an immediate pool in a VLIW bundle) subject to a set of esoteric
constraints.

Reviewers: t.p.northover

Subscribers: mgorny, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D67968

llvm-svn: 373718

show more ...

[gicombiner] Add the boring boilerplate for the declarative combiner

Summary:
This is the first of a series of patches extracted from a much bigger WIP
patch. It merely establishes the tblgen pass a

[gicombiner] Add the boring boilerplate for the declarative combiner

Summary:
This is the first of a series of patches extracted from a much bigger WIP
patch. It merely establishes the tblgen pass and the way empty combiner
helpers are declared and integrated into a combiner info.

The tablegen pass takes a -combiners option to select the combiner helper
that will be generated. This can be given multiple values to generate
multiple combiner helpers at once. Doing so helps to minimize parsing
overhead.

The reason for creating a GlobalISel subdirectory in utils/TableGen is that
there will be quite a lot of non-pass files (~15) by the time the patch
series is done.

Reviewers: volkan

Subscribers: mgorny, hiraditya, simoncook, Petar.Avramovic, s.egerton, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68286

llvm-svn: 373527

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.

Summary:
The pfm counters are now in the ExegesisTarget rather than the
MCSchedModel (PR39165).

This also compresses the pfm count

[MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.

Summary:
The pfm counters are now in the ExegesisTarget rather than the
MCSchedModel (PR39165).

This also compresses the pfm counter tables (PR37068).

Reviewers: RKSimon, gchatelet

Subscribers: mgrang, llvm-commits

Differential Revision: https://reviews.llvm.org/D52932

llvm-svn: 345243

show more ...

[WebAssembly][NFC] Remove WebAssemblyStackifier TableGen backend

Summary:
Replace its functionality with a TableGen InstrInfo relational
instruction mapping. Although arguably more complex than the

[WebAssembly][NFC] Remove WebAssemblyStackifier TableGen backend

Summary:
Replace its functionality with a TableGen InstrInfo relational
instruction mapping. Although arguably more complex than the TableGen
backend, the relational mapping is a smaller maintenance burden than a
TableGen backend.

Reviewers: aardappel, aheejin, dschuff

Subscribers: mgorny, sbc100, jgravelle-google, sunfish, llvm-commits

Differential Revision: https://reviews.llvm.org/D53307

llvm-svn: 344962

show more ...

[WebAssembly] TableGen backend for stackifying instructions

Summary:
The new stackification backend generates the giant switch statement
used to translate instructions to their stackified forms. I d

[WebAssembly] TableGen backend for stackifying instructions

Summary:
The new stackification backend generates the giant switch statement
used to translate instructions to their stackified forms. I did this
because it was more interesting than adding all the different vector
versions of the various SIMD instructions to the switch statment
manually.

Reviewers: aardappel, aheejin, dschuff

Subscribers: mgorny, sbc100, jgravelle-google, sunfish, jfb, llvm-commits

Differential Revision: https://reviews.llvm.org/D51318

llvm-svn: 340781

show more ...

[IR] Split Intrinsics.inc into enums and implementations

Implements PR34259

Intrinsics.h is a very popular header. Most LLVM TUs care about things
like dbg_value, but they don't care how they are i

[IR] Split Intrinsics.inc into enums and implementations

Implements PR34259

Intrinsics.h is a very popular header. Most LLVM TUs care about things
like dbg_value, but they don't care how they are implemented. After I
split these out, IntrinsicImpl.inc is 1.7 MB, so this saves each LLVM TU
from scanning 1.7 MB of source that gets pre-processed away.

It also means we can modify intrinsic properties without triggering a
full rebuild, but that's probably less of a win.

I think the next best thing to do would be to split out the target
intrinsics into their own header. Very, very few TUs care about
target-specific intrinsics. It's very hard to split up the target
independent intrinsics like llvm.expect, assume, and dbg.value, though.

llvm-svn: 335407

show more ...

[RISCV] Tablegen-driven Instruction Compression.

Summary:

This patch implements a tablegen-driven Instruction Compression
mechanism for generating RISCV compressed instructions
(C Exten

[RISCV] Tablegen-driven Instruction Compression.

Summary:

This patch implements a tablegen-driven Instruction Compression
mechanism for generating RISCV compressed instructions
(C Extension) from the expanded instruction form.

This tablegen backend processes CompressPat declarations in a
td file and generates all the compile-time and runtime checks
required to validate the declarations, validate the input
operands and generate correct instructions.

The checks include validating register operands, immediate
operands, fixed register operands and fixed immediate operands.

Example:
class CompressPat<dag input, dag output> {
dag Input = input;
dag Output = output;
list<Predicate> Predicates = [];
}

let Predicates = [HasStdExtC] in {
def : CompressPat<(ADD GPRNoX0:$rs1, GPRNoX0:$rs1, GPRNoX0:$rs2),
(C_ADD GPRNoX0:$rs1, GPRNoX0:$rs2)>;
}

The result is an auto-generated header file
'RISCVGenCompressEmitter.inc' which exports two functions for
compressing/uncompressing MCInst instructions, plus
some helper functions:

bool compressInst(MCInst& OutInst, const MCInst &MI,
const MCSubtargetInfo &STI,
MCContext &Context);

bool uncompressInst(MCInst& OutInst, const MCInst &MI,
const MCRegisterInfo &MRI,
const MCSubtargetInfo &STI);

The clients that include this auto-generated header file and
invoke these functions can compress an instruction before emitting
it, in the target-specific ASM or ELF streamer, or can uncompress
an instruction before printing it, when the expanded instruction
format aliases is favored.

The following clients were added to implement compression\uncompression
for RISCV:

1) RISCVAsmParser::MatchAndEmitInstruction:
Inserted a call to compressInst() to compresses instructions
parsed by llvm-mc coming from an ASM input.
2) RISCVAsmPrinter::EmitInstruction:
Inserted a call to compressInst() to compress instructions that
were lowered from Machine Instructions (MachineInstr).
3) RVInstPrinter::printInst:
Inserted a call to uncompressInst() to print the expanded
version of the instruction instead of the compressed one (e.g,
add s0, s0, a5 instead of c.add s0, a5) when -riscv-no-aliases
is not passed.

This patch squashes D45119, D42780 and D41932. It was reviewed in smaller patches by
asb, efriedma, apazos and mgrang.

Reviewers: asb, efriedma, apazos, llvm-commits, sabuasal

Reviewed By: sabuasal

Subscribers: mgorny, eraman, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, niosHD, kito-cheng, shiva0217, zzheng

Differential Revision: https://reviews.llvm.org/D45385

llvm-svn: 329455

show more ...

[Docs] Add tablegen backend for target opcode documentation

This is a tablegen backend to generate documentation for the opcodes that exist
for each target. For each opcode, it lists the assembly st

[Docs] Add tablegen backend for target opcode documentation

This is a tablegen backend to generate documentation for the opcodes that exist
for each target. For each opcode, it lists the assembly string, the names and
types of all operands, and the flags and predicates that apply to the opcode.

Differential revision: https://reviews.llvm.org/D31025

llvm-svn: 318155

show more ...

[X86][TableGen] Recommitting the X86 memory folding tables TableGen backend while disabling it by default.

After the original commit ([[ https://reviews.llvm.org/rL304088 | rL304088 ]]) was reverted

[X86][TableGen] Recommitting the X86 memory folding tables TableGen backend while disabling it by default.

After the original commit ([[ https://reviews.llvm.org/rL304088 | rL304088 ]]) was reverted, a discussion in llvm-dev was opened on 'how to accomplish this task'.
In the discussion we concluded that the best way to achieve our goal (which is to automate the folding tables and remove the manually maintained tables) is:

# Commit the tablegen backend disabled by default.

# Proceed with an incremental updating of the manual tables - while checking the validity of each added entry.

# Repeat previous step until we reach a state where the generated and the manual tables are identical. Then we can safely remove the manual tables and include the generated tables instead.

# Schedule periodical (1 week/2 weeks/1 month) runs of the pass:

- if changes appear (new entries):
- make sure the entries are legal
- If they are not, mark them as illegal to folding
- Commit the changes (if there are any).

CMake flag added for this purpose is "X86_GEN_FOLD_TABLES". Building with this flags will run the pass and emit the X86GenFoldTables.inc file under build/lib/Target/X86/ directory which is a good reference for any developer who wants to take part in the effort of completing the current folding tables.

Differential Revision: https://reviews.llvm.org/D38028

llvm-svn: 315173

show more ...

[x86] Revert the X86FoldTablesEmitter due to more miscompiles.

In testing, we've found yet another miscompile caused by the new tables.
And this one is even less clear how to fix (we could teach it

[x86] Revert the X86FoldTablesEmitter due to more miscompiles.

In testing, we've found yet another miscompile caused by the new tables.
And this one is even less clear how to fix (we could teach it to fold
a 16-bit load instead of the 32-bit load it wants, or block folding
entirely).

Also, the approach to excluding instructions seems increasingly to not
scale well.

I have left a more detailed analysis on the review log for the original
patch (https://reviews.llvm.org/D32684) along with suggested path
forward. I will land an additional test case that I wrote which covers
the code that was miscompiling (folding into the output of `pextrw`) in
a subsequent commit to keep this a pure revert.

For each commit reverted here, I've restricted the revert to the
non-test code touching the x86 fold table emission until the last commit
where I did revert the test updates. This means the *new* test cases
added for `insertps` and `xchg` remain untouched (and continue to pass).

Reverted commits:
r304540: [X86] Don't fold into memory operands into insertps in the ...
r304347: [TableGen] Adapt more places to getValueAsString now ...
r304163: [X86] Don't fold away the memory operand of an xchg.
r304123: Don't capture a temporary std::string in a StringRef.
r304122: Resubmit "[X86] Adding new LLVM TableGen backend that ..."

Original commit was in r304088, and after a string of fixes was reverted
previously in r304121 to fix build bots, and then re-landed in r304122.

llvm-svn: 304762

show more ...