Cygwin is like Windows in that it uses COFF, and doesn't emit
.debug_frame on 64-bit architectures.
However, if -elf is appended to the target triple on Cygwin MCJIT remote
tests fail due to `__register_frame` not being defined. Only one test
fails without -elf that succeeds with it, so mark just that test as
XFAIL on Cygwin.
When profcheck is enabled (presumably on a specific build bot), we want to ignore FileCheck because we're only interested in profile validation, and some tests are sensitive to the precise IR output, which profile validation alters slightly by inserting profile metadata.
Issue #147390
Add embedding generation functionality to the llvm-ir2vec tool, complementing the existing triplet generation mode.
This change completes the IR2Vec tool by adding the embedding generation functionality, which was previously mentioned as a TODO item. The tool now supports both triplet generation for vocabulary training and embedding generation using a trained vocabulary.
Add a new LLVM tool `llvm-ir2vec`. This tool is primarily intended to generate triplets for training the vocabulary (#141834) and to potentially generate the embeddings in a stand alone manner.
This PR introduces the tool with triplet generation functionality. In the upcoming PRs I'll add scripts under `utils/mlgo` to complete the vocabulary tooling. #147844 adds embedding generation logic to the tool.
(Tracking issue - #141817)
This patch adds initial support for Integrated Distributed ThinLTO
(DTLTO) in LLVM, which manages distribution internally during the
traditional link step. This enables compatibility with any build
system that supports in-process ThinLTO. In contrast, existing
approaches to distributed ThinLTO, which split the thin-link
(--thinlto-index-only), backend compilation, and final link into
separate steps, require build system support, e.g. Bazel.
This patch implements the core DTLTO mechanism, which enables
delegation of ThinLTO backend jobs to an external process (the
distributor). The distributor can then manage job distribution through
systems like Incredibuild. A generic JSON interface is used to
communicate with the distributor, allowing for the creation of new
distributors (and thus integration with different distribution
systems) without modifying LLVM.
Please see llvm/docs/dtlto.rst for more details.
RFC: https://discourse.llvm.org/t/rfc-integrated-distributed-thinlto/69641
Design Review: https://github.com/llvm/llvm-project/pull/126654
Linux perf_events is not implemented in WSL1, skip the test that
requires it.
There is just a single test that requires perf_events. It fails under
WSL1 with:
```sh
env JITDUMPDIR=/home/meinersbur/build/llvm-project/release/test/ExecutionEngine/JITLink/x86-64/Output/ELF_perf.s.tmp /home/meinersbur/build/llvm-project/release/bin/llvm-jitlink -perf-support /home/meinersbur/build/llvm-project/release/test/ExecutionEngine/JITLink/x86-64/Output/ELF_perf.s.tmp/ELF_x86-64_perf.o
llvm-jitlink error: PerfState not initialized
```
WSL environment detection logic follows
https://github.com/scivision/detect-windows-subsystem-for-linux/blob/main/is_wsl.py
Also see WSL issue: https://github.com/microsoft/WSL/issues/4595
Re-enables compact-unwind support in JITLink, which was reverted in b04847b427d
due to buildbot failures.
The underlying cause for the failures on the buildbots was the lack of
compact-unwind registration support on older Darwin OSes. Since the
CompactUnwindManager pass now removes eh-frames by default we were left with
unwind-info that could not be registered. On x86-64, where eh-frame info is
produced by default the solution is to fall back to using eh-frames. On arm64
we simply can't support exceptions on older OSes.
This patch updates the EHFrameRegistrationPlugin to remove the compact-unwind
section (__LD,__compact_unwind) when installed, forcing use of eh-frames when
the EHFrameRegistrationPlugin is used. In LLJIT, the EHFrameRegistrationPlugin
continues to be used for all non-Darwin platform, and will be added on Darwin
platforms when the a CompactUnwindRegistrationPlugin instance can't be created
(e.g. due to missing support for compact-unwind info registration).
The lit.cfg.py script is updated to check whether the host OSes default unwind
info supports JIT registration, allowing tests to be disabled for older Darwin
OSes on arm64.
This adds a flag to lit for detecting and updating failing tests when
possible to do so automatically. The flag uses a plugin architecture
where config files can add additional auto-updaters for the types of
tests in the test suite. When a test fails with `--update-tests` enabled
lit passes the test RUN invocation and output to each registered test
updater until one of them signals that it updated the test (or all test
updaters have been run). As such it is the responsibility of the test
updater to only update tests where it is reasonably certain that it will
actually fix the test, or come close to doing so.
Initially adds support for UpdateVerifyTests and UpdateTestChecks. The
flag is currently only implemented for lit's internal shell, so
`--update-tests` implies `LIT_USE_INTERNAL_SHELL=1`.
Builds on work in #97369Fixes#81320
I came across the subtly when setting up lit for z/OS and running it on
a Linux on Power machine. Linux on Power is little endian. This was
resulting in all of these tests being run even though the target triple
was z/OS which is big endian. The lit should really be checking if the
target is little endian not the host. The previous way didn't handle
cross compilation while running lit.
### 2nd submission
The buildbots are using python 3.8, and some type annotations I was
using are only available starting 3.9. The last commit on the pile is
the additional changes compared to the original submission
https://github.com/llvm/llvm-project/pull/104020.
### Original text:
Currently, the testing infrastructure for SPIR-V is based on FileCheck.
Those tests are great to check some level of codegen, but when the test
needs check both the CFG layout and the content of each basic-block,
things becomes messy.
Because the CHECK/CHECK-DAG/CHECK-NEXT state is limited, it is sometimes
hard to catch the good block: if 2 basic blocks have similar
instructions, FileCheck can match the wrong one.
Cross-lane interaction can be a bit difficult to understand, and
writting a FileCheck test that is strong enough to catch bad CFG
transforms while not being broken everytime some unrelated codegen part
changes is hard.
And lastly, the spirv-val tooling we have checks that the generated
SPIR-V respects the spec, not that it is correct in regards to the
source IR.
For those reasons, I believe the best way to test the structurizer is
to:
run spirv-val to make sure the CFG respects the spec.
simulate the function to validate result for each lane, making sure the
generated code is correct.
This simulator has no other dependencies than core python. It also only
supports a very limited set of instructions as we can test most features
through control-flow and some basic cross-lane interactions.
As-is, the added tests are just a harness for the simulator itself. If
this gets merged, the structurizer PR will benefit from this as I'll be
able to add extensive testing using this.
---------
Signed-off-by: Nathan Gauër <brioche@google.com>
Currently, the testing infrastructure for SPIR-V is based on FileCheck.
Those tests are great to check some level of codegen, but when the test
needs check both the CFG layout and the content of each basic-block,
things becomes messy.
- Because the CHECK/CHECK-DAG/CHECK-NEXT state is limited, it is
sometimes hard to catch the good block: if 2 basic blocks have similar
instructions, FileCheck can match the wrong one.
- Cross-lane interaction can be a bit difficult to understand, and
writting a FileCheck test that is strong enough to catch bad CFG
transforms while not being broken everytime some unrelated codegen part
changes is hard.
And lastly, the spirv-val tooling we have checks that the generated
SPIR-V respects the spec, not that it is correct in regards to the
source IR.
For those reasons, I believe the best way to test the structurizer is
to:
- run spirv-val to make sure the CFG respects the spec.
- simulate the function to validate result for each lane, making sure
the generated code is correct.
This simulator has no other dependencies than core python. It also only
supports a very limited set of instructions as we can test most features
through control-flow and some basic cross-lane interactions.
As-is, the added tests are just a harness for the simulator itself. If
this gets merged, the structurizer PR will benefit from this as I'll be
able to add extensive testing using this.
---------
Signed-off-by: Nathan Gauër <brioche@google.com>
Reland [CGData] llvm-cgdata #89884 using `Opt` instead of `cl`
- Action options are required, `--convert`, `--show`, `--merge`. This
was similar to sub-commands previously implemented, but having a prefix
`--`.
- `--format` option is added, which specifies `text` or `binary`.
---------
Co-authored-by: Kyungwoo Lee <kyulee@fb.com>
This is a tool to simplify testing. It generates a valid contextual profile file from a json representation.
The tool is authored to allow for future evolution, e.g. if we want to support profile merging or other tasks, not necessarily scoped to testing.
The llvm-cgdata tool has been introduced to handle reading and writing
of codegen data. This data includes an optimistic codegen summary that
can be utilized to enhance subsequent codegen. Currently, the tool
supports saving and restoring the outlined hash tree, facilitating
machine function outlining across modules. Additional codegen summaries
can be incorporated into separate sections as required. This patch
primarily establishes basic support for the reader and writer, similar
to llvm-profdata.
The high-level operations of llvm-cgdata are as follows:
1. It reads local raw codegen data from a custom section (for example,
__llvm_outline) embedded in native binary files
2. It merges local raw codegen data into an indexed codegen data,
complete with a suitable header.
3. It handles reading and writing of the indexed codegen data into a
standalone file.
This depends on https://github.com/llvm/llvm-project/pull/89792.
This is a patch for
https://discourse.llvm.org/t/rfc-enhanced-machine-outliner-part-2-thinlto-nolto/78753.
---------
Co-authored-by: Kyungwoo Lee <kyulee@fb.com>
This is a second attempt to land #84501 which failed on several targets.
This patch adds the HAS_IEE754_FLOAT128 define which makes the check for
typedef'ing float128 more precise by checking whether __uint128_t is
available and checking if the host does not use __ibm128 which is
prevalent on power pc targets and replaces IEEE754 float128s.
This is a second attempt to land #84501 which failed on several targets.
This patch adds the HAS_IEE754_FLOAT128 define which makes the check for
typedef'ing float128 more precise by checking whether __uint128_t is available
and checking if the host does not use __ibm128 which is prevalent on power pc
targets and replaces IEEE754 float128s.
This patch enables constant folding for 128 bit floating-point logf
calls. This is achieved by querying if the host system has the logf128()
symbol available with a CMake test. If so, replace the runtime call with
the compile time value returned from logf128.
AF_UNIX sockets were added to Windows 10 build 17063 in 2017, older
versions of Windows will fail this test.
Also add a lit config so lit tests using sockets can do:
// REQUIRES: unix-sockets
(It would be cool if unit tests could use lit available_features)
Also fix llvm-config test that didn't fail when new libs are added.
We now have 64-bit XCOFF object file support, so these tests can be
enabled again. However, some tests still fail due to unsupported debug
sections, so I cleaned up their comments.
The const.cpp testcase fails when running in MSVC mode, while it does
succeed in MinGW mode.
In MSVC mode, there are more constructor invocations than expected, as
the printout looks like this:
A(1), this = 0000025597930000
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
A(1), this = 0000025597930000
f: this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
~A, this = 0000025597930000, val = 1
While the expected printout looks like this:
A(1), this = 000002C903E10000
f: this = 000002C903E10000, val = 1
f: this = 000002C903E10000, val = 1
~A, this = 000002C903E10000, val = 1
Reapplying #70991 with the XFAIL changed to check the host triple, not
the target triple. On an MSVC based build of Clang, but with the default
target triple set to PS4/PS5, we will still see the failure. And a Linux
based build of Clang that targets PS4/PS5 won't see the issue.
It's no longer possible to submit bitcode apps to the Apple App Store.
The tools
used to create xar archived bitcode sections inside MachO files have
been
discontinued. Additionally, the xar APIs have been deprecated since
macOS 12,
so this change removes unnecessary code from objdump and all
dependencies on
libxar.
This fixes rdar://116600767
This is the first of transition tapi-diff to be readtapi.
This tool will eventually replace functionality for Xcode's `xcrun tapi stubify` and
`xcrun tapi archive`.
This patch updates the tool name and is a minor refactor for the driver to handle more options.
Reviewed By: zixuw
Differential Revision: https://reviews.llvm.org/D153045
CUDA-12 no longer supports 32-bit compilation.
Tests agnostic to 32/64 compilation mode are switched to use nvptx64.
Tests that do care about it have 32-bit ptxas compilation disabled with cuda-12+.
Differential Revision: https://reviews.llvm.org/D152199
Assume the MSVC style naming only for "windows-msvc" targets.
After the previous attempt, this was changed to use the host triple
instead of the target.
Differential Revision: https://reviews.llvm.org/D149998
llvm-debuginfod intrinsically requires cpp-httplib to operate, so
exclude the target if it's unavailable. Right now the tool walks off an
llvm_unreachable.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D147185
Also get rid of explicitly specified '-march' values for old architectures.
This simplifies %ptxas-verify statements.
After the change, we can potentially miss cases where a new functionality
is added to the architecture without appropriate checks in the
backend. On the other hand, this is mostly true for old architectures
that have been thoroughly tested.
Differential Revision: https://reviews.llvm.org/D141736
This is part of effort in removing -enable-new-pm flag.
As a prat of this effort one of example passes SimplifyCFG must
be ported to new PM which will allow to remove the flag
calls from the tests that are using this pass.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D137103
We are in the process of retiring LLVM_HAVE_TF_API in favor of
LLVM_HAVE_TFLITE. This patch takes care of the transition in
llvm/test.
Differential Revision: https://reviews.llvm.org/D140133
test/ExecutionEngine/MCJIT/2005-12-02-TailCallBug.ll has
'XFAIL: mcjit-ia32' but that feature isn't defined anywhere, so
the XFAIL can't have any effect. This has not been a problem
because apparently there are no 32-bit x86 bots out there.
I found this as part of other work to clean up lit keywords, so
I figured I would go ahead and fix it. Verified by hacking my
lit.site.cfg.py so host_triple = target_triple = "i686-pc-windows-msvc"
and the test correctly reported XFAIL.
The test was added in D114846 but missed one place to introduce the
'httplib' feature keyword, so it has been UNSUPPORTED everywhere.
Differential Revision: https://reviews.llvm.org/D136613
