This patch makes the PPC and X86 Exegesis TargetTests use TestBase to
provide initial setup rather than doing it themselves. This promotes
code reuse a little bit and makes the tests a bit more consistent (with
MIPS and with the initial RISC-V tests landing soon).
-Use MCRegister::id() for BitVector index.
-Replace std::unordered_set<unsigned> with std::set<MCRegister.
There are other std::sets for Register. None for MCRegister before this.
I'm assuming we can have operator<(MCRegister, MCRegister). This avoids
needing to add std::hash<MCRegister>.
-Use MCRegister::isValid() to avoid comparing to 0.
While llvm-exegesis has explicit support for setting EFLAGS which
contains DF, it can be nice sometimes to explicitly set DF, especially
given that it is modeled as a separate register within LLVM. This patch
adds the ability to do that by lowering setting the value to 0 or 1 to
cld and std respectively.
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
This patch makes X86 llvm-exegesis unconditionally use older
instructions to load the lower vector registers, rather than trying to
use AVX512 for everything when available. This fixes a case where we
would try and load AVX512 registers using the older instructions if such
a snippet was constructed while -mcpu was set to something that did not
support AVX512. This would lead to a machine code verification error
rather than resulting in incomplete snippet setup, which seems to be the
intention of how this should work.
Fixes#114691.
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.
Three `llvm-exegesis` tests
```
LLVM-Unit :: tools/llvm-exegesis/./LLVMExegesisTests/SubprocessMemoryTest/DefinitionFillsCompletely
LLVM-Unit :: tools/llvm-exegesis/./LLVMExegesisTests/SubprocessMemoryTest/MultipleDefinitions
LLVM-Unit :: tools/llvm-exegesis/./LLVMExegesisTests/SubprocessMemoryTest/OneDefinition
```
`FAIL` on Linux/sparc64 like
```
llvm/unittests/tools/llvm-exegesis/X86/SubprocessMemoryTest.cpp:68: Failure
Expected equality of these values:
SharedMemoryMapping[I]
Which is: '\0'
ExpectedValue[I]
Which is: '\xAA' (170)
```
It seems like this test only works on little-endian hosts: three
sub-tests are already disabled on powerpc and s390x (both big-endian),
and the fourth is additionally guarded against big-endian hosts (making
the other guards unnecessary).
However, since it's not been analyzed if this is really an endianess
issue, this patch disables the whole test on powerpc and s390x as before
adding sparc to the mix.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
This reverts commit 1fe9c417a0bf143f9bb9f9e1fbf7b20f44196883.
This relands commit 6bbe8a296ee91754d423c59c35727eaa624f7140.
This was causing build failures on one of the ARMv8 builders. Still not
completely sure why, but relanding it to see if the failure pops up
again. If it does, the plan is to fix forward by disabling tests on ARM
temporarily as llvm-exegesis does not currently use SubprocessMemory
on ARM.
This reverts commit 8003f553a01a9a2a7eb09fe07e88f1ba9ee7d3a7.
This (and/or a related commit) was causing build failures on one of the
buildbots that needs more investigation. More information is available
at https://lab.llvm.org/buildbot/#/builders/178/builds/7015.
This reverts commit aefad27096bba513f06162fac2763089578f3de4.
This relands commit 6bbe8a296ee91754d423c59c35727eaa624f7140.
This patch was casuing build failures on non-Linux platforms due to the
default implementations for the functions not being updated. This ended
up causing out-of-line definition errors. Fixed for the relanding.
This reverts commit 6bbe8a296ee91754d423c59c35727eaa624f7140.
This breaks building LLVM on macOS, failing with
llvm/tools/llvm-exegesis/lib/SubprocessMemory.cpp:146:33: error: out-of-line definition of 'setupAuxiliaryMemoryInSubprocess' does not match any declaration in 'llvm::exegesis::SubprocessMemory'
Expected<int> SubprocessMemory::setupAuxiliaryMemoryInSubprocess(
This patch adds the thread ID to the subprocess memory shared memory
names. This avoids conflicts for downstream consumers that might want to
consume llvm-exegesis across multiple threads, which would otherwise run
into conflicts due to the same PID running multiple instances.
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).
This patch replaces --num-repetitions with --min-instructions to make it
more clear that the value refers to the minimum number of instructions
in the final assembled snippet rather than the number of repetitions of
the snippet. This patch also refactors some llvm-exegesis internal
variable names to reflect the name change.
Fixes#76890.
This patch refactors the instantiation of BenchmarkMeasure within all
the unit tests to use BenchmarkMeasure::Create rather than through
direct struct instantialization. This allows us to change what values
are stored in BenchmarkMeasure without getting compiler warnings on
every instantiation in the unit tests, and is also just a cleanup in
general as the Create function didn't seem to exist at the time the unit
tests were originally written.
Currently, the duplicate snippet repetitor will truncate snippets that
do not exactly divide the minimum number of instructions. This patch
corrects that behavior by making the duplicate snippet repetitor
duplicate the snippet in its entirety until the minimum number of
instructions has been reached.
This makes the behavior consistent with the loop snippet repetitor,
which will execute at least `--num-repetitions` (soon to be renamed
`--min-instructions`) instructions.
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.
Currently, the unit tests for the BenchmarkResult struct do not check if
the register initial values can be parsed back in. This patch adds a
matcher and tests that the register initial values can be parsed
correctly. This exercises code already contained within the benchmark to
yaml infrastructure.
The llvm-exegesis unit tests currently fail on PPC after
ceb196d9903f4db7250bbc6c8da13eeae1b85886 landed as the default page size
on most common linux distributions for PPC is 64kb rather than 4kb. This
patch changes the memory mappings to have addresses as multiples of 64kb
rather than multiples of 4kb to fix this issue.
This patch refactors the MMAP platform-specific preprocessor directives
in llvm-exegesis to a single file instead of having duplicate code split
across multiple files. These originally got introduced to get buildbots
green again due to platform specific failures.
This reverts commit 30d700117b772d94d8474ec56bd6f9cc423fc613.
This relands commit 3ab41f912a6c219a93b87c257139822ea07c8863.
When I was updating the patch to use llvm::to_integer, I only ran the
lit tests and didn't run the unit tests, one of which started to fail.
This patch fixes the broken unit test.
This test was an exact duplicate of the one above, providing no value,
and also adding confusion as it referred to a behavior that (was
presumably) moved around and tested differently during the review
process with the test being forgotten about.
Make sure the TestCount const definition is guarded the same way
as the use of the constant.
This is an attempt to fix buildbot failures related to
-Wunused-const-variable.
This patch makes SubprocessMemoryTest use process PIDs during creation
of the SubprocessMemory objects within the tests so that there isn't
interference between multiple instances of the test running at the same
time which could potentially occur in multi-user environments.
This is a continuation the review in https://reviews.llvm.org/D154680.
Some 32-bit architectures don't have mmap and define mmap2 instead.
E.g. on riscv32 we may get
```
| /mnt/b/yoe/master/build/tmp/work-shared/llvm-project-source-17.0.0-r0/git/llvm/tools/llvm-exegesis/lib/X86/Target.cpp:1116:19: error: use of undeclared identifier 'SYS_mmap'
| 1116 | generateSyscall(SYS_mmap, MmapCode);
| | ^
| /mnt/b/yoe/master/build/tmp/work-shared/llvm-project-source-17.0.0-r0/git/llvm/tools/llvm-exegesis/lib/X86/Target.cpp:1134:19: error: use of undeclared identifier 'SYS_mmap'
| 1134 | generateSyscall(SYS_mmap, GeneratedCode); | | ^
| 1 warning and 2 errors generated.
```
Co-Authored-By: Fangrui Song <i@maskray.me>
Differential Revision: https://reviews.llvm.org/D158375
Having the SubprocessMemory class available on Android was causing build
failures in downstream builds as Android doesn't implement the SystemV
IPC specification that supplies shm_open and other functions that the
class relies on. This patch simply makes it unavailable on Android using
preprocessor directives.
This patch adds memory annotation parsing to llvm-exegesis. The memory
annotations cannot be used currently, but this allows for using parsed
memory annotations within a FunctionExecutorImpl to set up a specified
execution environment.
I fixed compilation on 32-bit ARM earlier in the -Werror case using
preprocessor directives but forgot to update the unit tests that also
depend upon that value. This patch updates the unit tests as well as a
quick fix for the builders that were broken by the earlier patch.
llvm-exegesis currently isn't compiling on 32-bit ARM due to SYS_mmap
not being defined as 32-bit ARM instead uses SYS_mmap2. This patch
defines SYS_mmap to be SYS_mmap2 in the relevant places to allow for
compilation to succeed.
Some builders are currently failing as they don't have
MAP_FIXED_NOREPLACE available. This patch checks if MAP_FIXED_NOREPLACE
is available and if it isn't, it is simply defined as MAP_FIXED.
On some platforms such as PPC shm_open is in librt and it isn't
automatically linked against. This patch explicitly links against librt
in the unittests which should hopefully fix the symbol resolution
errors.
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
This patch changes to disabling tests in SubprocessMemoryTest.cpp using
preprocessor directives rather than pulling the file out of the build
using CMake. This is the de facto canonical way to do it in the rest of
the tree as seen in other unittest files such as DwarfDebugInfoTest.cpp.
This patch introduces the SubprocessMemory class to llvm-exegesis. This
class contains several utilities that are needed for managing memory to
set up an execution environment for memory annotations.
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D151022
This reverts commit 0b6b400b98b921279fc08c63a2a68ebfcb12a3e2.
The sporadic test failures were fixed during this land, but I forgot to
fix the build failures on certain platforms (seems to mostly be
AArch64/PPC) that result from them not being able to find the symbols
for shm_open and shm_unlink.
This patch introduces the SubprocessMemory class to llvm-exegesis. This
class contains several utilities that are needed for managing memory to
set up an execution environment for memory annotations.
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D151022
This reverts commit 1b9b78fd481a13b54afaf4804ee4ad18fcf006fd.
There are spurious test failures on the ml-* bots and some of the ARM
builders are complaining about shm_open being missing. Pulling this
commit so that I can investigate after I sleep.
This patch introduces the SubprocessMemory class to llvm-exegesis. This
class contains several utilities that are needed for managing memory to
set up an execution environment for memory annotations.
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D151022
Remove the warning caused by a missing field initializer.
The field is `StartAtCycle` of `struct MCWriteProcResEntry`.
It has been set to the default `StartAtCycle = 0`.
Differential Revision: https://reviews.llvm.org/D150569
The Assembler tests have been disabled for years in tree and at this
point don't test anything other than common MC infrastructure that is
already tested in other parts of the tree. This patch removes them due
to the mentioned reasons.
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D149819
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
The new methods return a range for easier iteration. Use them everywhere
instead of getImplicitUses, getNumImplicitUses, getImplicitDefs and
getNumImplicitDefs. A future patch will remove the old methods.
In some use cases the new methods are less efficient because they always
have to scan the whole uses/defs array to count its length, but that
will be fixed in a future patch by storing the number of implicit
uses/defs explicitly in MCInstrDesc. At that point there will be no need
to 0-terminate the arrays.
Differential Revision: https://reviews.llvm.org/D142215
When trying to measure latency of certain opcodes, e.g.
`./bin/llvm-exegesis --opcode-name=BT32ri8 --mode=latency --repetition-mode=loop --benchmarks-file=- --max-configs-per-opcode=65536`,
we'd pick such an aliasing instruction, and such an aliasing registers,
that would alias with forbidden registers.
And in particular with loop counter in `loop` repetition mode,
which made the measurements never finish.
This does not address all such cases, only the most obvious one.
The added test case fails without the patch.
Fixes https://github.com/llvm/llvm-project/issues/59441
