[CodeGen] Move instruction predicate verification to emitInstruction

D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added

[CodeGen] Move instruction predicate verification to emitInstruction

D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.

This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.

The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.

Recommitted with some fixes for the leftover MCII variables in release
builds.

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

show more ...

Revert "Move instruction predicate verification to emitInstruction"

This reverts commit e2fb8c0f4b940e0285ee36c112469fa75d4b60ff as it does
not build for Release builds, and some buildbots are givin

Revert "Move instruction predicate verification to emitInstruction"

This reverts commit e2fb8c0f4b940e0285ee36c112469fa75d4b60ff as it does
not build for Release builds, and some buildbots are giving more warning
than I saw locally. Reverting to fix those issues.

show more ...

Move instruction predicate verification to emitInstruction

D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Targ

Move instruction predicate verification to emitInstruction

D25618 added a method to verify the instruction predicates for an
emitted instruction, through verifyInstructionPredicates added into
<Target>MCCodeEmitter::encodeInstruction. This is a very useful idea,
but the implementation inside MCCodeEmitter made it only fire for object
files, not assembly which most of the llvm test suite uses.

This patch moves the code into the <Target>_MC::verifyInstructionPredicates
method, inside the InstrInfo. The allows it to be called from other
places, such as in this patch where it is called from the
<Target>AsmPrinter::emitInstruction methods which should trigger for
both assembly and object files. It can also be called from other places
such as verifyInstruction, but that is not done here (it tends to catch
errors earlier, but in reality just shows all the mir tests that have
incorrect feature predicates). The interface was also simplified
slightly, moving computeAvailableFeatures into the function so that it
does not need to be called externally.

The ARM, AMDGPU (but not R600), AVR, Mips and X86 backends all currently
show errors in the test-suite, so have been disabled with FIXME
comments.

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

show more ...

[TableGen][CodeEmitterGen] Do not crash on insufficient positional instruction operands.

Reviewed By: foad

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

[CodeEmitter] Fix encoding wide instructions on big-endian hosts

For instructions wider than 64 bits the InstBits table is initialized in
64-bit chunks from APInt::getRawData, but it was being read

[CodeEmitter] Fix encoding wide instructions on big-endian hosts

For instructions wider than 64 bits the InstBits table is initialized in
64-bit chunks from APInt::getRawData, but it was being read with
LoadIntFromMemory which is byte-based.

Fix this by reading the table with the APInt constructor that takes an
ArrayRef to the raw data instead.

This is currently NFC for in-tree targets but fixes AMDGPU failures on
big-endian hosts that were caused by D126483 until it was reverted.

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

show more ...

[TableGen][CodeEmitter] Introducing the VarLenCodeEmitterGen infrastructure

Full write up:
https://gist.github.com/mshockwave/66e98d099256deefc062633909bb7b5b

The existing CodeEmitterGen infrastruc

[TableGen][CodeEmitter] Introducing the VarLenCodeEmitterGen infrastructure

Full write up:
https://gist.github.com/mshockwave/66e98d099256deefc062633909bb7b5b

The existing CodeEmitterGen infrastructure is unable to generate encoder
function for ISAs with variable-length instructions. This patch
introduces a new infrastructure to support variable-length instruction
encoding, including a new TableGen syntax for writing instruction
encoding directives and a new TableGen backend component,
VarLenCodeEmitterGen, built on top of CodeEmitterGen.

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

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] CodeEmitterGen - emit report_fatal_error(const char*) instead of report_fatal_error(std::string&)

As described on D111049, we're trying to remove the <string> dependency from error handli

[TableGen] CodeEmitterGen - emit report_fatal_error(const char*) instead of report_fatal_error(std::string&)

As described on D111049, we're trying to remove the <string> dependency from error handling. In most cases the plan is to use the Twine() variant directly but to reduce introducing additional headers for the generated files, I'm using the const char* variant here instead.

show more ...

[TableGen] Fix warning when compiling generated MCCodeEmitter

This fixes an instance of:
warning: cast from 'const unsigned long *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
when comp

[TableGen] Fix warning when compiling generated MCCodeEmitter

This fixes an instance of:
warning: cast from 'const unsigned long *' to 'unsigned char *' drops const qualifier [-Wcast-qual]
when compiling the generated MCCodeEmitter for an out-of-tree target
that uses the optional support for instruction widths > 64 bits.

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

show more ...

[TableGen] Make the map in InfoByHwMode protected. NFCI

Switch some for loops to just use the begin()/end() implementations
in the InfoByHwMode struct.

Add a method to insert into the map for the o

[TableGen] Make the map in InfoByHwMode protected. NFCI

Switch some for loops to just use the begin()/end() implementations
in the InfoByHwMode struct.

Add a method to insert into the map for the one case that was
modifying the map directly.

show more ...

[TableGen] Use range-based for loops (NFC)

[TableGen] Add field kind to the RecordVal class.

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

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

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] Fixes -Wrange-loop-analysis warnings

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

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

[TableGen] Fix crash when using HwModes in CodeEmitterGen

When an instruction has an encoding definition for only a subset of
the available HwModes, ensure we just avoid generating an encoding
rathe

[TableGen] Fix crash when using HwModes in CodeEmitterGen

When an instruction has an encoding definition for only a subset of
the available HwModes, ensure we just avoid generating an encoding
rather than crash.

llvm-svn: 374150

show more ...

[TableGen] Support encoding per-HwMode

Much like ValueTypeByHwMode/RegInfoByHwMode, this patch allows targets
to modify an instruction's encoding based on HwMode. When the
EncodingInfos field is non

[TableGen] Support encoding per-HwMode

Much like ValueTypeByHwMode/RegInfoByHwMode, this patch allows targets
to modify an instruction's encoding based on HwMode. When the
EncodingInfos field is non-empty the Inst and Size fields of the Instruction
are ignored and taken from EncodingInfos instead.

As part of this promote getHwMode() from TargetSubtargetInfo to MCSubtargetInfo.

This is NFC for all existing targets - new code is generated only if targets
use EncodingByHwMode.

llvm-svn: 372320

show more ...

Fix compile-time regression caused by rL371928

Summary:
Also fixup rL371928 for cases that occur on our out-of-tree backend

There were still quite a few intermediate APInts and this caused the
comp

Fix compile-time regression caused by rL371928

Summary:
Also fixup rL371928 for cases that occur on our out-of-tree backend

There were still quite a few intermediate APInts and this caused the
compile time of MCCodeEmitter for our target to jump from 16s up to
~5m40s. This patch, brings it back down to ~17s by eliminating pretty
much all of them using two new APInt functions (extractBitsAsZExtValue(),
insertBits() but with a uint64_t). The exact conditions for eliminating
them is that the field extracted/inserted must be <=64-bit which is
almost always true.

Note: The two new APInt API's assume that APInt::WordSize is at least
64-bit because that means they touch at most 2 APInt words. They
statically assert that's true. It seems very unlikely that someone
is patching it to be smaller so this should be fine.

Reviewers: jmolloy

Reviewed By: jmolloy

Subscribers: hiraditya, dexonsmith, llvm-commits

Tags: #llvm

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

llvm-svn: 372243

show more ...

[CodeEmitter] Support instruction widths > 64 bits

Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).

This change switches CodeEmit

[CodeEmitter] Support instruction widths > 64 bits

Some VLIW instruction sets are Very Long Indeed. Using uint64_t constricts the Inst encoding to 64 bits (naturally).

This change switches CodeEmitter to a mode that uses APInts when Inst's bitwidth is > 64 bits (NFC for existing targets).

When Inst.BitWidth > 64 the prototype changes to:

void TargetMCCodeEmitter::getBinaryCodeForInstr(const MCInst &MI,
SmallVectorImpl<MCFixup> &Fixups,
APInt &Inst,
APInt &Scratch,
const MCSubtargetInfo &STI);

The Inst parameter returns the encoded instruction, the Scratch parameter is used internally for manipulating operands and is exposed so that the underlying storage can be reused between calls to getBinaryCodeForInstr. The goal is to elide any APInt constructions that we can.

Similarly the operand encoding prototype changes to:

getMachineOpValue(const MCInst &MI, const MCOperand &MO, APInt &op, SmallVectorImpl<MCFixup> &Fixups, const MCSubtargetInfo &STI);

That is, the operand is passed by reference as APInt rather than returned as uint64_t.

To reiterate, this APInt mode is enabled only when Inst.BitWidth > 64, so this change is NFC for existing targets.

llvm-svn: 371928

show more ...

Use a bit of relaxed constexpr to make FeatureBitset costant intializable

This requires std::intializer_list to be a literal type, which it is
starting with C++14. The downside is that std::bitset i

Use a bit of relaxed constexpr to make FeatureBitset costant intializable

This requires std::intializer_list to be a literal type, which it is
starting with C++14. The downside is that std::bitset is still not
constexpr-friendly so this change contains a re-implementation of most
of it.

Shrinks clang by ~60k.

llvm-svn: 369847

show more ...

Use bitset for assembler predicates

AMDGPU target run out of Subtarget feature flags hitting the limit of 64.
AssemblerPredicates uses at most uint64_t for their representation.
At the same time Cod

Use bitset for assembler predicates

AMDGPU target run out of Subtarget feature flags hitting the limit of 64.
AssemblerPredicates uses at most uint64_t for their representation.
At the same time CodeGen has exhausted this a long time ago and switched
to a FeatureBitset with the current limit of 192 bits.

This patch completes transition to the bitset for feature bits extending
it to asm matcher and MC code emitter.

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

llvm-svn: 355839

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] Avoid creating a temporary vector in getInstructionCase

Record::getValues returns ArrayRef which has a cast operator
to std::vector, as a result a temporary vector is created
if the type

[tablegen] Avoid creating a temporary vector in getInstructionCase

Record::getValues returns ArrayRef which has a cast operator
to std::vector, as a result a temporary vector is created
if the type of the variable is const std::vector&
that is suboptimal in this case.

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

Test plan: make check-all

llvm-svn: 307063

show more ...

[TableGen] Adapt more places to getValueAsString now returning a StringRef instead of a std::string.

llvm-svn: 304347

[TableGen] Make Record::getValueAsString and getValueAsListOfStrings return StringRefs instead of std::string

Internally both these methods just return the result of getValue on either a StringInit

[TableGen] Make Record::getValueAsString and getValueAsListOfStrings return StringRefs instead of std::string

Internally both these methods just return the result of getValue on either a StringInit or a CodeInit object. In both cases this returns a StringRef pointing to a string allocated in the BumpPtrAllocator so its not going anywhere. So we can just pass that StringRef along.

This is a fairly naive patch that targets just the build failures caused by this change. There's additional work that can be done to avoid creating std::string at call sites that still think getValueAsString returns a std::string. I'll try to clean those up in future patches.

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

llvm-svn: 304325

show more ...