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

[llvm-exegesis] Switch from intptr_t to uintptr_t in most cases (#102860)

This patch switches most of the uses of intptr_t to uintptr_t within
llvm-exegesis for the subprocess memory support. In th

[llvm-exegesis] Switch from intptr_t to uintptr_t in most cases (#102860)

This patch switches most of the uses of intptr_t to uintptr_t within
llvm-exegesis for the subprocess memory support. In the vast majority of
cases we do not want a signed component of the address, hence making
intptr_t undesirable. intptr_t is left for error handling, for example
when making syscalls and we need to see if the syscall returned -1.

show more ...

[llvm-exegesis] Add loop-register snippet annotation (#82873)

This patch adds a LLVM-EXEGESIS-LOOP-REGISTER snippet annotation which
allows a user to specify the register to use for the loop counte

[llvm-exegesis] Add loop-register snippet annotation (#82873)

This patch adds a LLVM-EXEGESIS-LOOP-REGISTER snippet annotation which
allows a user to specify the register to use for the loop counter in the
loop repetition mode. This allows for executing snippets that don't work
with the default value (currently R8 on X86).

show more ...

[llvm-exegesis][NFC] Refactor all `ValidationEvent` info in a single … (#82256)

…table.

All data is derived from a single table rather than being spread out
over an enum, a table and the main en

[llvm-exegesis][NFC] Refactor all `ValidationEvent` info in a single … (#82256)

…table.

All data is derived from a single table rather than being spread out
over an enum, a table and the main entry point.

This is intended as a replacement for #82092.

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] Update validation counters enum

To be consistent with f65265ab779f5c6c571ff702aae5670722765ae0.

[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 Target Memory Utility Functions

This patch adds in several functions to ExegesisTarget that will assist
in setting up memory for the planned memory annotations.

Reviewed By: cou

[llvm-exegesis] Add Target Memory Utility Functions

This patch adds in several functions to ExegesisTarget that will assist
in setting up memory for the planned memory annotations.

Reviewed By: courbet

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

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

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

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

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.

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

Use `__builtin_ia32_fxsave64` under __GNUC__, (_fxsave64) does not exist in old versions of
gcc (pre-9.1).

This reverts comm

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

Use `__builtin_ia32_fxsave64` under __GNUC__, (_fxsave64) does not exist in old versions of
gcc (pre-9.1).

This reverts commit e128f9cafca4e72b089fcd1381af5a1ec656d987.

show more ...

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

_fxsave64 is not available on some buildbots.

This reverts commit 274de447fe9621082a523a7227157aeb84702a7d.