Cleanup include: TableGen

This also includes a few cleanup from Support.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.l

Cleanup include: TableGen

This also includes a few cleanup from Support.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121331

show more ...

utils: Remove some no-op raw_string_ostream flush calls, NFC

Since 65b13610a5226b84889b923bae884ba395ad084d, raw_string_ostream has
been unbuffered by default. Based on an audit of llvm/utils/, this

utils: Remove some no-op raw_string_ostream flush calls, NFC

Since 65b13610a5226b84889b923bae884ba395ad084d, raw_string_ostream has
been unbuffered by default. Based on an audit of llvm/utils/, this
commit removes every call to `raw_string_ostream::flush()` and any call
to `raw_string_ostream::str()` whose result is ignored or that doesn't
help with clarity.

I left behind a few calls to `str()`. In these cases, the underlying
std::string was declared pretty far away and never used again, whereas
stream recently had its last write. The code is easier to read as-is;
the no-op call to `flush()` inside `str()` isn't harmful, and when
https://reviews.llvm.org/D115421 lands it'll be gone anyway.

show more ...

[TableGen] Use sign rotated VBR for OPC_EmitInteger.

This allows for a much more efficient encoding for small negative
numbers by storing the sign bit first and negating the rest of
the bits. This w

[TableGen] Use sign rotated VBR for OPC_EmitInteger.

This allows for a much more efficient encoding for small negative
numbers by storing the sign bit first and negating the rest of
the bits. This was already being used for OPC_CheckInteger.

For every in tree target this affects, the table got smaller.
R600GenDAGISel.inc saw the largest reduction of 7K.

I did have to add a new opcode for StringIntegers used for
register class ids and subregister indices since we don't have the
integer value to encode. The enum name is emitted directly into
the table. Previously assumed the enum would expand to a positive
7-bit number. We might be able to just shift that right by 1 and
assume it is a positive 6 bit number, but that will need more
investigation.

show more ...

[TableGen] Avoid repeated TreePredicateFn::getCodeToRunOnSDNode() calls in MatcherTableEmitter::EmitNodePredicatesFunction loop. NFCI.

[TableGen][SelectionDAG] Improve efficiency of encoding negative immediates for isel's CheckInteger opcode.

CheckInteger uses an int64_t encoded using a variable width encoding
that is optimized for

[TableGen][SelectionDAG] Improve efficiency of encoding negative immediates for isel's CheckInteger opcode.

CheckInteger uses an int64_t encoded using a variable width encoding
that is optimized for encoding a number with a lot of leading zeros.
Negative numbers have no leading zeros so use the largest encoding
requiring 9 bytes.

I believe its most like we want to check for positive and negative
numbers near 0. -1 is quite common due to its use in the 'not'
idiom.

To optimize for this, we can borrow an idea from the bitcode format
and move the sign bit to bit 0 with the magnitude stored in the
upper bits. This will drastically increase the number of leading
zeros for small magnitudes. Then we can run this value through
VBR encoding.

This gives a small reduction in the table size on all in tree
targets except VE where size increased by about 300 bytes due
to intrinsic ids now requiring 3 bytes instead of 2. Since the
intrinsic enum space is shared by all targets this an unfortunate
consquence of where VE is currently located in the range.

Reviewed By: RKSimon

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

show more ...

[TableGen] Use return value from EmitVBRValue instead of calling GetVBRSize on the same value. Consistently use unsigned for child sizes. NFCI

getSize and setSize both use unsigned. So size_t doesn'

[TableGen] Use return value from EmitVBRValue instead of calling GetVBRSize on the same value. Consistently use unsigned for child sizes. NFCI

getSize and setSize both use unsigned. So size_t doesn't
increase range here and might get truncated if passed to
setSize.

Also not sure why EmitVBRValue was returning uint64_t, but used
an unsigned to supply the value.

show more ...

[TableGen] [ISel Matcher Emitter] Rework with two passes: one to size, one to emit

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

[TableGen] Indentation and whitespace fixes in generated code. NFC.

Some of these were found by running clang-format over the generated
code, although that complains about far more issues than I hav

[TableGen] Indentation and whitespace fixes in generated code. NFC.

Some of these were found by running clang-format over the generated
code, although that complains about far more issues than I have fixed
here.

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

show more ...

llvm-tblgen -gen-dag-isel: Hoist SmallVector TmpBuf

llvm-tblgen -gen-dag-isel: Reduce lib/Target/*/*GenDAGISel.inc

X86GenDAGISel.inc: 22597697 bytes -> 20874981 bytes

[TBLGEN] Fix subreg value overflow in DAGISelMatcher

Tablegen's DAGISelMatcher emits integers in a VBR format,
so if an integer is below 128 it can fit into a single
byte, otherwise high bit is set,

[TBLGEN] Fix subreg value overflow in DAGISelMatcher

Tablegen's DAGISelMatcher emits integers in a VBR format,
so if an integer is below 128 it can fit into a single
byte, otherwise high bit is set, next byte is used etc.
MatcherTable is essentially an unsigned char table. When
SelectionDAGISel parses the table it does a reverse translation.

In a situation when numeric value of an integer to emit is
unknown it can be emitted not as OPC_EmitInteger but as
OPC_EmitStringInteger using a symbolic name of the value.
In this situation the value should not exceed 127.

One of the situations when OPC_EmitStringInteger is used is
if we need to emit a subreg into a matcher table. However,
number of subregs can exceed 127. Currently last defined subreg
for AMDGPU is 192. That results in a silent bug in the ISel
with matcher reading from an invalid offset.

Fixed this bug to emit actual VBR encoded value for a subregs
which value exceeds 127.

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

show more ...

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

TableGen: Support physical register inputs > 255

This was truncating register value that didn't fit in unsigned char.
Switch AMDGPU sendmsg intrinsics to using a tablegen pattern.

llvm-svn: 366695

Recommit r355224 "[TableGen][SelectionDAG][X86] Add specific isel matchers for immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary."

Includes a fix to emit a Che

Recommit r355224 "[TableGen][SelectionDAG][X86] Add specific isel matchers for immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary."

Includes a fix to emit a CheckOpcode for build_vector when immAllZerosV/immAllOnesV is used as a pattern root. This means it can't be used to look through bitcasts when used as a root, but that's probably ok. This extra CheckOpcode will ensure that the first match in the isel table will be a SwitchOpcode which is needed by the caching optimization in the ISel Matcher.

Original commit message:

Previously we had build_vector PatFrags that called ISD::isBuildVectorAllZeros/Ones. Internally the ISD::isBuildVectorAllZeros/Ones look through bitcasts, but we aren't able to take advantage of that in isel. Instead of we have to canonicalize the types of the all zeros/ones build_vectors and insert bitcasts. Then we have to pattern match those exact bitcasts.

By emitting specific matchers for these 2 nodes, we can make isel look through any bitcasts without needing to explicitly match them. We should also be able to remove the canonicalization to vXi32 from lowering, but I've left that for a follow up.

This removes something like 40,000 bytes from the X86 isel table.

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

llvm-svn: 355784

show more ...

Revert r355224 "[TableGen][SelectionDAG][X86] Add specific isel matchers for immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary."

This caused the first matcher

Revert r355224 "[TableGen][SelectionDAG][X86] Add specific isel matchers for immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary."

This caused the first matcher in the isel table for many targets to Opc_Scope instead of Opc_SwitchOpcode. This leads to a significant increase in isel match failures.

llvm-svn: 355433

show more ...

[TableGen][SelectionDAG][X86] Add specific isel matchers for immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary.

Previously we had build_vector PatFrags that ca

[TableGen][SelectionDAG][X86] Add specific isel matchers for immAllZerosV/immAllOnesV. Remove bitcasts from X86 patterns that are no longer necessary.

Previously we had build_vector PatFrags that called ISD::isBuildVectorAllZeros/Ones. Internally the ISD::isBuildVectorAllZeros/Ones look through bitcasts, but we aren't able to take advantage of that in isel. Instead of we have to canonicalize the types of the all zeros/ones build_vectors and insert bitcasts. Then we have to pattern match those exact bitcasts.

By emitting specific matchers for these 2 nodes, we can make isel look through any bitcasts without needing to explicitly match them. We should also be able to remove the canonicalization to vXi32 from lowering, but I've left that for a follow up.

This removes something like 40,000 bytes from the X86 isel table.

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

llvm-svn: 355224

show more ...

[SelectionDAG] Add a OPC_CheckChild2CondCode to SelectionDAGISel to remove a MoveChild and MoveParent pair.

OPC_CheckCondCode is always used as operand 2 of a setcc. And its always surrounded by a M

[SelectionDAG] Add a OPC_CheckChild2CondCode to SelectionDAGISel to remove a MoveChild and MoveParent pair.

OPC_CheckCondCode is always used as operand 2 of a setcc. And its always surrounded by a MoveChild2 and a MoveParent. By having a dedicated opcode for this case we can reduce the number of bytes needed for this pattern from 4 bytes to 2.

This saves ~3000 bytes in the X86 table.

llvm-svn: 354763

show more ...

[Tablegen][DAG]: Fix build breakage when LLVM_ENABLE_DAGISEL_COV=1

LLVM_ENABLE_DAGISEL_COV can be used to instrument DAGISel tablegen
selection code to show which patterns along with Complex pattern

[Tablegen][DAG]: Fix build breakage when LLVM_ENABLE_DAGISEL_COV=1

LLVM_ENABLE_DAGISEL_COV can be used to instrument DAGISel tablegen
selection code to show which patterns along with Complex patterns were
used when selecting instructions. Unfortunately this is turned off by
default and was broken but never tested.
This required a simple fix (missing new line) to get it to build again.

llvm-svn: 353091

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 ...

TableGen/ISel: Allow PatFrag predicate code to access captured operands

Summary:
This simplifies writing predicates for pattern fragments that are
automatically re-associated or commuted.

For examp

TableGen/ISel: Allow PatFrag predicate code to access captured operands

Summary:
This simplifies writing predicates for pattern fragments that are
automatically re-associated or commuted.

For example, a followup patch adds patterns for fragments of the form
(add (shl $x, $y), $z) to the AMDGPU backend. Such patterns are
automatically commuted to (add $z, (shl $x, $y)), which makes it basically
impossible to refer to $x, $y, and $z generically in the PredicateCode.

With this change, the PredicateCode can refer to $x, $y, and $z simply
as `Operands[i]`.

Test confirmed that there are no changes to any of the generated files
when building all (non-experimental) targets.

Change-Id: I61c00ace7eed42c1d4edc4c5351174b56b77a79c

Reviewers: arsenm, rampitec, RKSimon, craig.topper, hfinkel, uweigand

Subscribers: wdng, tpr, llvm-commits

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

llvm-svn: 347992

show more ...

[SelectionDAG] Add a isel matcher op to check the type of node results other than result 0.

I plan to use this to check the type of the mask result of masked gathers in the X86 backend.

llvm-svn: 3

[SelectionDAG] Add a isel matcher op to check the type of node results other than result 0.

I plan to use this to check the type of the mask result of masked gathers in the X86 backend.

llvm-svn: 318820

show more ...

Allow separation of declarations and definitions in <Target>ISelDAGToDAG.inc

This patch adds the ability to include the member function declarations
in the instruction selector class separately from

Allow separation of declarations and definitions in <Target>ISelDAGToDAG.inc

This patch adds the ability to include the member function declarations
in the instruction selector class separately from the member bodies.

Defining GET_DAGISEL_DECL macro to any value will only include the member
declarations. To include bodies, define GET_DAGISEL_BODY macro to be the
selector class name. Example:

class FooDAGToDAGISel : public SelectionDAGISel {
// Pull in declarations only.
#define GET_DAGISEL_DECL
#include "FooISelDAGToDAG.inc"
};

// Include the function bodies (with names qualified with the provided
// class name).
#define GET_DAGISEL_BODY FooDAGToDAGISel
#include "FooISelDAGToDAG.inc"

When neither of the two macros are defined, the function bodies are emitted
inline (in the same way as before this patch).

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

llvm-svn: 317903

show more ...

[TableGen] Add an extra blank line to DAGISel output file to separate functions.

llvm-svn: 317298

Strip trailing whitespace

llvm-svn: 315070

[TableGen] Generate formatted DAGISelEmitter without relying on formatted_raw_ostream.

The generated DAG isel file currently makes use of formatted_raw_ostream primarily for generating a hierarchica

[TableGen] Generate formatted DAGISelEmitter without relying on formatted_raw_ostream.

The generated DAG isel file currently makes use of formatted_raw_ostream primarily for generating a hierarchical representation while also skipping over the initial comment that contains the current index.

It was reported in D37957 that this formatting might be slow due to the need to keep track of column numbers by monitoring all the written data for new lines.

This patch attempts to rewrite the emitter to make use of simpler formatting mechanisms to generate a fairly similar output. The main difference is that the number in the index comment is now right justified and padded with spaces inside the comment. Previously we appended the spaces after the comment.

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

llvm-svn: 313674

show more ...