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
llvm-debuginfo-analyzer is a command line tool that processes debug
info contained in a binary file and produces a debug information
format agnostic “Logical View”, which is a high-level semantic
representation of the debug info, independent of the low-level
format.
The code has been divided into the following patches:
1) Interval tree
2) Driver and documentation
3) Logical elements
4) Locations and ranges
5) Select elements
6) Warning and internal options
7) Compare elements
8) ELF Reader
9) CodeView Reader
Full details:
https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-information-visual-analyzer/62570
This patch:
Driver and documentation
- Command line options.
- Full documentation.
- String Pool table.
Reviewed By: psamolysov, probinson
Differential Revision: https://reviews.llvm.org/D125777
1) Fixed a typo in PTXAS_EXECUTABLE CMake variable (PXTAS -> PTXAS).
2) Version check was implemented incorrectly,
now version (major, minor) is converted to int for comparison.
3) ptxas -arch argument was incorrect (or missing) in 3 tests.
Differential Revision: https://reviews.llvm.org/D127866
Disable debug-frame tests on AppleSilicon Mac to improve some of the fix
in PR46647.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D134896
This patch disables MC/ELF/cfi-version.ll test as windows does not emit
.debug_frame needed by the test. This was previously disabled for arm64
but windows on arm uses aarch64-pc-windows* triple. Replacing arm64 with
aarch64 to accomodate windows aarch64 triple(s).
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D134863
This adds llvm-remarkutil. This is intended to be a general tool for doing stuff
with/to remark files.
This patch gives it the following powers:
* `bitstream2yaml` - To convert bitstream remarks to YAML
* `yaml2bitstream` - To convert YAML remarks to bitstream remarks
These are both implemented as subcommands, like
`llvm-remarkutil bitstream2yaml <input_file> -o -`
I ran into an issue where I had some bitstream remarks coming from CI, and I
wanted to be able to do stuff with them (e.g. visualize them). But then I
noticed we didn't have any tooling for doing that, so I decided to write this
thing.
Being able to output YAML as a start seemed like a good idea, since it
would allow people to reuse any tooling they may have written based around YAML
remarks.
Hopefully it can grow into a more featureful remark utility. :)
Currently there are is an outstanding performance issue (see the TODO) with
the bitstream2yaml case. I decided that I'd keep the tool small to start with
and have the yaml2bitstream and bitstream2yaml cases be symmetric.
Also I moved the remarks documentation to its own header because it seems
a little out of place with "basic commands" and "developer tools"; it's
really kind of its own thing.
Differential Revision: https://reviews.llvm.org/D133646
Summary:
1. Added a new option object mode -X for llvm-ar. In AIX OS , there is a object mode option -X for ar command.
please see the "-X mode" part of https://www.ibm.com/docs/ko/aix/7.1?topic=ar-command
Specifies the type of object file ar should examine. The mode must be one of the following:
32
Processes only 32-bit object files
64
Processes only 64-bit object files
32_64
Processes both 32-bit and 64-bit object files
any
Processes all of the supported object files.
The default is to process 32-bit object files (ignore 64-bit objects). The mode can also be set with the OBJECT_MODE environment variable. For example, OBJECT_MODE=64 causes ar to process any 64-bit objects and ignore 32-bit objects. The -X flag overrides the OBJECT_MODE variable.
2. Before adding the new option -X, the default behaviors of llvm-ar like -Xany, but after the adding the new option -X, the default behaviors of llvm-ar change to -X32 ,in order to let some test cases which has 32bit and 64bit object file in the same llvm-ar command, we need to add the "export OBJECT_MODE=any" into test case to change the default behaviors of llvm-ar's object mode.
Reviewers: James Henderson, Owen Reynolds, Fangrui Song
Differential Revision: https://reviews.llvm.org/D127864
This patch implements proposal https://lists.llvm.org/pipermail/llvm-dev/2020-August/144579.html
llvm-dwarfutil - is a tool that is used for processing debug info(DWARF) located in built binary files to improve debug info quality, reduce debug info size. The patch currently implements smaller set of command-line options(comparing to the proposal):
```
./llvm-dwarfutil [options] <input file> <output file>
--garbage-collection Do garbage collection for debug info(default)
-j <value> Alias for --num-threads
--no-garbage-collection Don`t do garbage collection for debug info
--no-odr-deduplication Don`t do ODR deduplication for debug types
--no-odr Alias for --no-odr-deduplication
--no-separate-debug-file
Create single output file, containing debug tables(default)
--num-threads <threads> Number of available threads for multi-threaded execution. Defaults to the number of cores on the current machine
--odr-deduplication Do ODR deduplication for debug types(default)
--odr Alias for --odr-deduplication
--separate-debug-file Create two output files: file w/o debug tables and file with debug tables
--tombstone [bfd,maxpc,exec,universal]
Tombstone value used as a marker of invalid address(default: universal)
=bfd - Zero for all addresses and [1,1] for DWARF v4 (or less) address ranges and exec
=maxpc - Minus 1 for all addresses and minus 2 for DWARF v4 (or less) address ranges
=exec - Match with address ranges of executable sections
=universal - Both: bfd and maxpc
```
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D86539
This patch implements proposal https://lists.llvm.org/pipermail/llvm-dev/2020-August/144579.html
llvm-dwarfutil - is a tool that is used for processing debug info(DWARF) located in built binary files to improve debug info quality, reduce debug info size. The patch currently implements smaller set of command-line options(comparing to the proposal):
```
./llvm-dwarfutil [options] <input file> <output file>
--garbage-collection Do garbage collection for debug info(default)
-j <value> Alias for --num-threads
--no-garbage-collection Don`t do garbage collection for debug info
--no-odr-deduplication Don`t do ODR deduplication for debug types
--no-odr Alias for --no-odr-deduplication
--no-separate-debug-file
Create single output file, containing debug tables(default)
--num-threads <threads> Number of available threads for multi-threaded execution. Defaults to the number of cores on the current machine
--odr-deduplication Do ODR deduplication for debug types(default)
--odr Alias for --odr-deduplication
--separate-debug-file Create two output files: file w/o debug tables and file with debug tables
--tombstone [bfd,maxpc,exec,universal]
Tombstone value used as a marker of invalid address(default: universal)
=bfd - Zero for all addresses and [1,1] for DWARF v4 (or less) address ranges and exec
=maxpc - Minus 1 for all addresses and minus 2 for DWARF v4 (or less) address ranges
=exec - Match with address ranges of executable sections
=universal - Both: bfd and maxpc
```
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D86539
This implements a debuginfod server in llvm using the `DebuginfodCollection` and `DebuginfodServer` classes. This is tested with lit tests against the debuginfod-find client.
The server scans 0 or more local directories for artifacts. It serves the debuginfod protocol over HTTP. Only the `executable` and `debuginfo` endpoints are supported (no `/source` endpoint).
The server also uses the debuginfod client as a fallback, so it can hit the local debuginfod cache or federate to other known debuginfod servers.
The client behavior is controllable through the standard environment variables (`DEBUGINFOD_URLS`, `DEBUGINFOD_CACHE_PATH`, `DEBUGINFOD_TIMEOUT`)
The server implements on-demand collection updates as follows:
If the build-id is not found by a local lookup, rescan immediately and look up the build-id again before returning 404. To protect against DoS attacks, do not rescan more frequently than once per N seconds (specified by `-m`).
Lit tests are provided which test the `llvm-debuginfod-find` client against the `llvm-debuginfod` server.
Reviewed By: mysterymath
Differential Revision: https://reviews.llvm.org/D114846
This patch adds an llvm-driver multicall tool that can combine multiple
LLVM-based tools. The build infrastructure is enabled for a tool by
adding the GENERATE_DRIVER option to the add_llvm_executable CMake
call, and changing the tool's main function to a canonicalized
tool_name_main format (i.e. llvm_ar_main, clang_main, etc...).
As currently implemented llvm-driver contains dsymutil, llvm-ar,
llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the
build).
llvm-driver can be enabled from builds by setting
LLVM_TOOL_LLVM_DRIVER_BUILD=On.
There are several limitations in the current implementation, which can
be addressed in subsequent patches:
(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.
These limitations can be addressed in subsequent patches.
Differential revision: https://reviews.llvm.org/D109977
