[llvm-exegesis] Begin replacing unsigned with MCRegister. NFC (#123109)

Some of this was needed to fix implicit conversions from MCRegister to
unsigned when calling getReg() on MCOperand for exampl

[llvm-exegesis] Begin replacing unsigned with MCRegister. NFC (#123109)

Some of this was needed to fix implicit conversions from MCRegister to
unsigned when calling getReg() on MCOperand for example.

The majority was done by reviewing parts of the code that dealt with
registers, converting them to MCRegister and then seeing what new
implicit conversions were created and fixing those.

There were a few places where I used MCPhysReg instead of MCRegiser for
static arrays since its uint16_t instead of unsigned.

show more ...

Overhaul the TargetMachine and LLVMTargetMachine Classes (#111234)

Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/

Overhaul the TargetMachine and LLVMTargetMachine Classes (#111234)

Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/117907.html,
https://reviews.llvm.org/D38482, https://reviews.llvm.org/D38489, this
PR attempts to overhaul the `TargetMachine` and `LLVMTargetMachine`
interface classes. More specifically:
1. Makes `TargetMachine` the only class implemented under
`TargetMachine.h` in the `Target` library.
2. `TargetMachine` contains target-specific interface functions that
relate to IR/CodeGen/MC constructs, whereas before (at least on paper)
it was supposed to have only IR/MC constructs. Any Target that doesn't
want to use the independent code generator simply does not implement
them, and returns either `false` or `nullptr`.
3. Renames `LLVMTargetMachine` to `CodeGenCommonTMImpl`. This renaming
aims to make the purpose of `LLVMTargetMachine` clearer. Its interface
was moved under the CodeGen library, to further emphasis its usage in
Targets that use CodeGen directly.
4. Makes `TargetMachine` the only interface used across LLVM and its
projects. With these changes, `CodeGenCommonTMImpl` is simply a set of
shared function implementations of `TargetMachine`, and CodeGen users
don't need to static cast to `LLVMTargetMachine` every time they need a
CodeGen-specific feature of the `TargetMachine`.
5. More importantly, does not change any requirements regarding library
linking.

cc @arsenm @aeubanks

show more ...

[llvm-exegesis] Refactor getting register number from name to LLVMState (#107895)

This patch refactors the procedure of getting the register number from a
register name to LLVMState rather than hav

[llvm-exegesis] Refactor getting register number from name to LLVMState (#107895)

This patch refactors the procedure of getting the register number from a
register name to LLVMState rather than having individual users get the
values themselves by getting a reference to the map from LLVMState. This
is primarily intended to make some downstream usage in Gematria simpler,
but also cleans up a little bit upstream by pulling the actual map
searching out and just leaving error handling to the clients.

The original getter is left to enable downstream migration in Gematria,
particularly before it gets imported into google internal.

show more ...

[llvm-exegesis] Use MCRegister instead of unsigned to hold registers (#107820)

[llvm-exegesis] Remove llvm prefix where unnecessary (#79802)

This patch removes the llvm:: prefix within llvm-exegesis where it is
not necessary. This is most occurrences of the prefix within exeg

[llvm-exegesis] Remove llvm prefix where unnecessary (#79802)

This patch removes the llvm:: prefix within llvm-exegesis where it is
not necessary. This is most occurrences of the prefix within exegesis as
exegesis is within the llvm namespace. This patch makes things more
consistent as the vast majority of the code did not use the llvm::
prefix for anything.

show more ...

[MC] Always encode instruction into SmallVector

All users of MCCodeEmitter::encodeInstruction use a raw_svector_ostream
to encode the instruction into a SmallVector. The raw_ostream however
incurs s

[MC] Always encode instruction into SmallVector

All users of MCCodeEmitter::encodeInstruction use a raw_svector_ostream
to encode the instruction into a SmallVector. The raw_ostream however
incurs some overhead for the actual encoding.

This change allows an MCCodeEmitter to directly emit an instruction into
a SmallVector without using a raw_ostream and therefore allow for
performance improvments in encoding. A default path that uses existing
raw_ostream implementations is provided.

Reviewed By: MaskRay, Amir

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

show more ...

[llvm-exegesis] Make possible to execute snippets without perf counters

Performance counters may be unavailable due to various reasons (such as
access restriction via sysctl properties or the CPU mo

[llvm-exegesis] Make possible to execute snippets without perf counters

Performance counters may be unavailable due to various reasons (such as
access restriction via sysctl properties or the CPU model being unknown
to libpfm). On the other hand, for debugging llvm-exegesis itself it is
still useful to be able to run generated code snippets to ensure that
the snippet does not crash at run time.

The --use-dummy-perf-counters command line option makes llvm-exegesis
behave just as usual except for using fake event counts instead of asking
the kernel for actual values.

~~

Huawei RRI, OS Lab

Reviewed By: courbet

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

show more ...

[NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC w

[NFC][TargetParser] Replace uses of llvm/Support/Host.h

The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.

show more ...

[NFC][llvm-exegesis] LLVMState: only store references to reg/op names

We know that the original reference from which we've built these maps
will persist, so we do not need to copy the names.

[NFC][Exegesis] Don't recompute opcode/reg names on each YAML write (-38% runtime)

This reducer runtime of
```
$ ./bin/llvm-exegesis -mode=inverse_throughput --opcode-index=-1 --benchmarks-file=/dev

[NFC][Exegesis] Don't recompute opcode/reg names on each YAML write (-38% runtime)

This reducer runtime of
```
$ ./bin/llvm-exegesis -mode=inverse_throughput --opcode-index=-1 --benchmarks-file=/dev/null --dump-object-to-disk=0 --measurements-print-progress --skip-measurements
```
from 3m44s to 2m17s, aka -38%.
But more importantly, we go from 400 *million* memory allocations
down to just 100 million, aka -75%.

But really, the big missing thing is doing everything in a single thread.
Sure, we can't do anything when measuring, but when we are not measuring,
we should just prepare (codegen) everything via all threads.
That should parallelize quite well.

show more ...

[llvm-exegesis] Dry run mode

Sometimes we only want to ensure that we can produce snippets (all the way
through `SnippetRepetitor`!), but don't care for the execution.
E.g. all of our tests are this

[llvm-exegesis] Dry run mode

Sometimes we only want to ensure that we can produce snippets (all the way
through `SnippetRepetitor`!), but don't care for the execution.
E.g. all of our tests are this way.

I've built LLVM without PFM and removed my CPU from `X86PfmCounters.td`,
and this produces the expected results in that configuration.

Reviewed By: courbet

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

show more ...

[llvm-exegesis][NFC] Use factory function for LlvmState.

This allows failing more gracefully.

[NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`

Reviewed By: skan

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

Revert "[NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`"

This reverts commit fe25c06cc5bdc2ef9427309f8ec1434aad69dc7a.

[NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`

For ten years, it seems that `MCRegisterInfo` is not used by any target.

Reviewed By: skan

Differential Revision: https://revie

[NFC][MC] remove unused argument `MCRegisterInfo` in `MCCodeEmitter`

For ten years, it seems that `MCRegisterInfo` is not used by any target.

Reviewed By: skan

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

show more ...

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

show more ...

[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo

This makes it possible for targets to define their own MCObjectFileInfo.
This MCObjectFileInfo is then used

[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo

This makes it possible for targets to define their own MCObjectFileInfo.
This MCObjectFileInfo is then used to determine things like section alignment.

This is a follow up to D101462 and prepares for the RISCV backend defining the
text section alignment depending on the enabled extensions.

Reviewed By: MaskRay

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

show more ...

[MC] Untangle MCContext and MCObjectFileInfo

This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
a

[MC] Untangle MCContext and MCObjectFileInfo

This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
also exists during construction: You can't contruct a MOFI without a MCContext
without constructing the MCContext with a dummy version of that MOFI first.
This removes this dependency during construction. In a perfect world,
MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the
MCContext, like other MC information. This is future work.

This also shifts/adds more information to the MCContext making it more
available to the different targets. Namely:

- TargetTriple
- ObjectFileType
- SubtargetInfo

Reviewed By: MaskRay

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

show more ...

[llvm][clang][mlir] Add checks for the return values from Target::createXXX to prevent protential null deref

All these potential null pointer dereferences are reported by my static analyzer for null

[llvm][clang][mlir] Add checks for the return values from Target::createXXX to prevent protential null deref

All these potential null pointer dereferences are reported by my static analyzer for null smart pointer dereferences, which has a different implementation from `alpha.cplusplus.SmartPtr`.

The checked pointers in this patch are initialized by Target::createXXX functions. When the creator function pointer is not correctly set, a null pointer will be returned, or the creator function may originally return a null pointer.

Some of them may not make sense as they may be checked before entering the function, but I fixed them all in this patch. I submit this fix because 1) similar checks are found in some other places in the LLVM codebase for the same return value of the function; and, 2) some of the pointers are dereferenced before they are checked, which may definitely trigger a null pointer dereference if the return value is nullptr.

Reviewed By: tejohnson, MaskRay, jpienaar

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

show more ...

Remove unused Endian.h includes, NFC

Mainly avoids including Host.h everywhere:

$ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \
| grep '^[-+] ' | sort | uniq -c | sort -nr
3

Remove unused Endian.h includes, NFC

Mainly avoids including Host.h everywhere:

$ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \
| grep '^[-+] ' | sort | uniq -c | sort -nr
3141 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Host.h

show more ...

[llvm-exegesis] Fix r374158

Some bots complain about missing 'class':

LlvmState.h:70:40: error: declaration of ‘std::unique_ptr<const llvm::TargetMachine> llvm::exegesis::LLVMState::TargetMachine’

[llvm-exegesis] Fix r374158

Some bots complain about missing 'class':

LlvmState.h:70:40: error: declaration of ‘std::unique_ptr<const llvm::TargetMachine> llvm::exegesis::LLVMState::TargetMachine’ [-fpermissive]
std::unique_ptr<const TargetMachine> TargetMachine;

llvm-svn: 374162

show more ...

[llvm-exegesis][NFC] Remove extra `llvm::` qualifications.

Summary: Second patch: in the lib.

Reviewers: gchatelet

Subscribers: nemanjai, tschuett, MaskRay, mgrang, jsji, llvm-commits

Tags: #llvm

[llvm-exegesis][NFC] Remove extra `llvm::` qualifications.

Summary: Second patch: in the lib.

Reviewers: gchatelet

Subscribers: nemanjai, tschuett, MaskRay, mgrang, jsji, llvm-commits

Tags: #llvm

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

llvm-svn: 374158

show more ...

[llvm-exegesis] Allow the target to disable the selection of some registers.

Summary:
This prevents "Cannot encode high byte register in REX-prefixed instruction"
from happening on instructions that

[llvm-exegesis] Allow the target to disable the selection of some registers.

Summary:
This prevents "Cannot encode high byte register in REX-prefixed instruction"
from happening on instructions that require REX encoding when AH & co
get selected.
On the down side, these 4 registers can no longer be selected
automatically, but this avoids having to expose all the X86 encoding
complexity.

Reviewers: gchatelet

Subscribers: tschuett, jdoerfert, llvm-commits, bdb

Tags: #llvm

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

llvm-svn: 357003

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

[llvm-exegesis][NFC] More tests for ExegesisTarget::fillMemoryOperands().

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits

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

llvm-svn:

[llvm-exegesis][NFC] More tests for ExegesisTarget::fillMemoryOperands().

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits

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

llvm-svn: 347209

show more ...