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

Revert "Reland: "[Exegesis] Add the ability to dry-run the measurement phase (#121991)" (#122775)"

This reverts commit a39aaf35d3858a5542f532e399482c2bb0259dac and
63d3bd6d0caf8185aba49540fe2f67512f

Revert "Reland: "[Exegesis] Add the ability to dry-run the measurement phase (#121991)" (#122775)"

This reverts commit a39aaf35d3858a5542f532e399482c2bb0259dac and
63d3bd6d0caf8185aba49540fe2f67512fdf3a98.

Due to test failures on MacOSX.

show more ...

Reland: "[Exegesis] Add the ability to dry-run the measurement phase (#121991)" (#122775)

This relands f8f8598fd886cddfd374fa43eb6d7d37d301b576

Follow up on #122371:
The problem here is a little

Reland: "[Exegesis] Add the ability to dry-run the measurement phase (#121991)" (#122775)

This relands f8f8598fd886cddfd374fa43eb6d7d37d301b576

Follow up on #122371:
The problem here is a little subtle: when we dry-run the measurement
phase, we create a LLJIT instance without actually executing the
snippets. The key is, LLJIT has its own TargetMachine which uses triple
designated by LLVM_TARGET_ARCH (which is default to host). On a machine
that does not support Exegesis, the LLJIT would fail to create its
TargetMachine because llvm-exegesis don't even register the host's
target!

Putting this test into any of the target-specific folder won't help,
because it's about the host. And personally I don't really want to use
`exegesis-can-execute-<arch>` for generic tests like this -- it's too
strict as we don't actually need to execute the snippet.

My solution here is creating another test feature which is added only
when LLVM_TARGET_ARCH is supported by llvm-exegesis. This feature is
something in between `<arch>-registered-target` and
`exegesis-can-execute-<arch>`.

show more ...

Revert "[Exegesis] Add the ability to dry-run the measurement phase (… (#122371)

…#121991)"

This reverts commit f8f8598fd886cddfd374fa43eb6d7d37d301b576.

This breaks ARMv7 and s390x buildbot w

Revert "[Exegesis] Add the ability to dry-run the measurement phase (… (#122371)

…#121991)"

This reverts commit f8f8598fd886cddfd374fa43eb6d7d37d301b576.

This breaks ARMv7 and s390x buildbot with the following message:
```
llvm-exegesis error: No available targets are compatible with triple "armv8l-unknown-linux-gnueabihf"
FileCheck error: '<stdin>' is empty.
FileCheck command line: /home/tcwg-buildbot/worker/clang-armv7-2stage/stage2/bin/FileCheck /home/tcwg-buildbot/worker/clang-armv7-2stage/llvm/llvm/test/tools/llvm-exegesis/dry-run-measurement.test
```

show more ...

[Exegesis] Add the ability to dry-run the measurement phase (#121991)

With the new benchmark phase, `dry-run-measurement`, llvm-exegesis can
run everything except the actual snippet execution. It i

[Exegesis] Add the ability to dry-run the measurement phase (#121991)

With the new benchmark phase, `dry-run-measurement`, llvm-exegesis can
run everything except the actual snippet execution. It is useful when we
want to test some parts of the code between the `assemble-measured-code`
and `measure` phase without actually running on native platforms.

show more ...

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

[llvm-exegesis] Add support for validation counters (#76653)

This patch adds support for validation counters. Validation counters can
be used to measure events that occur during snippet execution l

[llvm-exegesis] Add support for validation counters (#76653)

This patch adds support for validation counters. Validation counters can
be used to measure events that occur during snippet execution like cache
misses to ensure that certain assumed invariants about the benchmark
actually hold. Validation counters are setup within a perf event group,
so are turned on and off at exactly the same time as the "group leader"
counter that measures the desired value.

show more ...

[llvm-exegesis] Refactor Counter to CounterGroup (#77887)

This refactoring gets things ready for validation counters where the
plan is to reuse the existing Counter infrastructure to contain event

[llvm-exegesis] Refactor Counter to CounterGroup (#77887)

This refactoring gets things ready for validation counters where the
plan is to reuse the existing Counter infrastructure to contain event
groups that consist of a single event that is being measured along with
validation counters.

show more ...

[llvm-exegesis] Add tablegen support for validation counters (#76652)

This patch adds support in the llvm-exegesis tablegen emitter for
validation counters. Full support for validation counters in

[llvm-exegesis] Add tablegen support for validation counters (#76652)

This patch adds support in the llvm-exegesis tablegen emitter for
validation counters. Full support for validation counters in
llvm-exegesis will be added in a future patch.

show more ...

[llvm-exegesis] Add option to specify the number of measurement repetitions (#74276)

Currently, the llvm-exegesis LatencyBenchmarkRunner repeats the
benchmark several times (currently 30) and then

[llvm-exegesis] Add option to specify the number of measurement repetitions (#74276)

Currently, the llvm-exegesis LatencyBenchmarkRunner repeats the
benchmark several times (currently 30) and then aggregates the result to
deal with noise in the measurement process. With this patch, the number
of repetitions to perform is made configurable rather than left as a
static number. This allows for significantly faster execution in
situations where someone is performing a task like experimenting with
memory annotations where the exact cycle counts might not be useful, and
also allows for increased precision when desired.

show more ...

[llvm-exegesis] Prevent llvm-exegesis from using unsupported opcodes

When generating snippets for AArch64 with --opcode-index=-1, the code
generator asserts on opcodes that are not supported accordi

[llvm-exegesis] Prevent llvm-exegesis from using unsupported opcodes

When generating snippets for AArch64 with --opcode-index=-1, the code
generator asserts on opcodes that are not supported according to CPU
features.

The same assertion can be triggered even when generating a serial
snippet for a supported opcode if SERIAL_VIA_NON_MEMORY_INSTR execution
mode is used and an unsupported instruction is chosen as the "other
instruction". Unlike the first case, this one may result in flaky
failures because the other instruction is randomly chosen from the
instructions suitable for serializing execution.

This patch adjusts TableGen emitter for *GenInstrInfo.inc to make
possible to query for opcode availability instead of just asserting on
unsupported ones.

~~

Huawei RRI, OS Lab

Reviewed By: courbet

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

show more ...

[llvm-exegesis] Add ability to assign perf counters to specific PID

This patch gives the ability to assign performance counters within
llvm-exegesis to a specific process by passing its PID. This is

[llvm-exegesis] Add ability to assign perf counters to specific PID

This patch gives the ability to assign performance counters within
llvm-exegesis to a specific process by passing its PID. This is needed
later on for implementing a subprocess executor. Defaults to zero, the
current process, for the InProcessFunctionExecutorImpl.

Reviewed By: courbet

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

show more ...

Revert "[llvm-exegesis] Add ability to assign perf counters to specific PID"

Revert "[llvm-exegesis] Introduce Subprocess Executor Mode"

This reverts commit 5e9173c43a9b97c8614e36d6f754317f731e71e9

Revert "[llvm-exegesis] Add ability to assign perf counters to specific PID"

Revert "[llvm-exegesis] Introduce Subprocess Executor Mode"

This reverts commit 5e9173c43a9b97c8614e36d6f754317f731e71e9.
This reverts commit 4d618b52f6e05e41d35f56653cb36bf7d4dc794e.

Reverting the PID commit as it is currently breaking MinGW builds and
the way I'm checking for the presence of pid_t needs to be fixed and I
need to do some testing. The subprocess executor mode patch is a
dependent patch so also needs to be reverted and also needs some work as
it is currently failing tests where libpfm is installed and the kernel
version is less than 5.6.

show more ...

[llvm-exegesis] Add ability to assign perf counters to specific PID

This patch gives the ability to assign performance counters within
llvm-exegesis to a specific process by passing its PID. This is

[llvm-exegesis] Add ability to assign perf counters to specific PID

This patch gives the ability to assign performance counters within
llvm-exegesis to a specific process by passing its PID. This is needed
later on for implementing a subprocess executor. Defaults to zero, the
current process, for the InProcessFunctionExecutorImpl.

Reviewed By: courbet

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

show more ...

[llvm-exegesis] Refactor FunctionExecutorImpl and create factory

In order to better support adding in new implementations of
FunctionExecutor, this patch makes some small changes so that it is
easie

[llvm-exegesis] Refactor FunctionExecutorImpl and create factory

In order to better support adding in new implementations of
FunctionExecutor, this patch makes some small changes so that it is
easier to add new ones in. FunctionExecutorImpl is renamed to
InProcessFunctionExecutorImpl to better reflect how it will be placed
relative to the soon-to-be introduced subprocess executor and a new
function is created to create executors so selection can be done more
easily. In addition, a new CLI flag, -execution-mode, which can be used
to select between the different executors.

Reviewed By: courbet

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

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

[llvm-exegesis] Refactor InstructionBenchmark to Benchmark

When llvm-exegesis was first introduced, it only supported benchmarking
individual instructions, hence the name for the data structure stor

[llvm-exegesis] Refactor InstructionBenchmark to Benchmark

When llvm-exegesis was first introduced, it only supported benchmarking
individual instructions, hence the name for the data structure storing
the data corresponding to a benchmark being called InstructionBenchmark
made sense. However, now that benchmarking arbitrary snippets is
supported, InstructionBenchmark doesn't correspond to a single
instruction. This patch refactors InstructionBenchmark to be called
Benchmark to clean up this little bit of technical debt.

Reviewed By: courbet

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

show more ...

Migrate away from C++20-deprecated POD type traits

[exegesis] "Skip codegen" dry-run mode

While "skip measurements mode" is super useful for test coverage,
i've come to discover it's trade-offs. It still calls back-end
to actually codegen the target

[exegesis] "Skip codegen" dry-run mode

While "skip measurements mode" is super useful for test coverage,
i've come to discover it's trade-offs. It still calls back-end
to actually codegen the target assembly, and that is what is taking
80%+ of the time regardless of whether or not we skip the measurements.

On the other hand, just being able to see that exegesis can come up
with a snippet to measure something, is already very useful,
and takes maybe a second for a all-opcode sweep.

Reviewed By: gchatelet

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

show more ...

[NFC][llvm-exegesis] Ensure that target options show up in --help

Fixes https://github.com/llvm/llvm-project/issues/59377

[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] Use *::empty (NFC)

[llvm] Use llvm::lower_bound and llvm::upper_bound (NFC)

Re-land "[llvm-exegesis] Save target state before running the benchmark."

The X86 exegesis target is never executed run on non-X86 hosts, disable
X86 instrinsic code on non-X86 targets.

This revert

Re-land "[llvm-exegesis] Save target state before running the benchmark."

The X86 exegesis target is never executed run on non-X86 hosts, disable
X86 instrinsic code on non-X86 targets.

This reverts commit 8cfc872129a99782ab07a19171bf8eace85589ae.

show more ...

Revert "Re-land "[llvm-exegesis] Save target state before running the benchmark."

Still issues on some architectures.

This reverts commit fd13d7ce09af2bcad6976b8f5207874992bdd908.