The Clang-AIX-Wyvern-Dev buildbot is currently failing at the set
directory permission due to a bad symlink caused by this
[commit](a54f31fabd).
This change is creating the additional symlink `readtapi ->
llvm-readtapi` which causes it to appear in
`/buildbot_worker/official-worker/clang-aix-dev/installdir`.
After some investigation, it looks like `readtapi` is the only tool that
is getting symlinked that is not guarded by the
`LLVM_INSTALL_BINUTILS_SYMLINKS` macro. For example:
1. `llvm/tools/llvm-objcopy/CMakeLists.txt`
```
if(LLVM_INSTALL_BINUTILS_SYMLINKS)
add_llvm_tool_symlink(objcopy llvm-objcopy)
endif()
```
2. `llvm/tools/llvm-dwp/CMakeLists.txt`
```
if(LLVM_INSTALL_BINUTILS_SYMLINKS)
add_llvm_tool_symlink(dwp llvm-dwp)
endif()
```
Currently the email that gets sent out to people subscribing to a label
that the bot tags on the PR doesn't include any authorship information
which some people are interested in having. This patch adds an author
field to the message with the relevant information.
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
When `PredicateUsesOperands` is set to true, GlobalISelEmitter preserves
the original index of predicate operands and uses that information on
each predicate usage. However, previously it only looked up the original
index for "actual" operands (i.e. operands of a predicate usage) that
are leaf nodes, which is an incorrect assumption.
This patch fix it by generalizing the acceptable kinds of actual
operands for predicate as well as checking the existance of bound
predicate operands.
In PR #65242 (landed as 9e739fdb85ac672f3e25e971d96e71823e07ebda), I
claimed that RUN lines cannot contain newlines. Actually, they can after
substitution expansion. More generally, a lit config file can define
substitutions or preamble commands containing newlines. While both of
those cases seem unlikely in practice,
[D154987](https://reviews.llvm.org/D154987) proposes PYTHON directives
where it seems very likely.
Regardless of the use case, without this patch, such newlines break
expansion of `%dbg(RUN: at line N)`, and the fix is simple.
…the size of a pointer by HwMode.
This adds an equivalent of PtrValueType that can use a
ValueTypeByHwMode.
This allows the size of a pointer to vary based on HwMode. This is
needed for RISC-V to support XLen sized pointers.
X86 don't want to unfold RMW instrs to 1 load + 1 op + 1 store, because
RMW could save code size and benefit RA when reg pressure is high.
And from all the call position analysis, we could find we didn't unfold
RMW in current code.
common.itertests has useful functionality such as skipping test case if
it starts with UTC_AVOID comment string. It also does some of the
functionality, such as skipping test file pattern if not found, that was
duplicated by update_mca_test_checks.
This patch uses this function to take advantage of extra behavior and
remove duplication.
update_analyze_test_checks.py currently outputs a warning when updating
a script with the run line:
$ opt -passes='print<scalar-evolution>'
saying that the script doesn't support its output, when it indeed does,
as evidenced by several tests in test/Analysis/ScalarEvolution generated
by this script. There is even a test for update_analyze_test_checks that
makes sure that SCEV output is supported. Hence, squelch the warning.
While at it, rename the update_analyze_test_checks test from basic.ll to
a more explicit scev.ll.
This is mostly AMDGPU-specific. When the expensive checks are enabled,
generating of AMDGPUGenRegisterInfo.inc currently takes about 20 minutes
on my machine for release+asserts builds, which effectively prevents
such testing from regular use. This patch fixes this by reducing the
time to about 2 minutes.
Generation times for AMDGPUGenRegisterInfo.inc without expensive checks
and other *GenRegisterInfo.inc files with and without the expensive
checks remain approximately the same.
The patch doesn't cause any changes in the contents of the generated
files.
The root cause of the current poor performance is that where glibcxx is
used, enabling the expensive checks defines _GLIBCXX_DEBUG, which
enables various consistency checks in the library. One such check is in
std::binary_search() to make sure the range is ordered. As
CodeGenRegisterClass::contains() relies on std::binary_search() and it
is called very a large number of times from within
CodeGenRegBank::inferMatchingSuperRegClass(), the libcxx checks heavily
affect the runtimes.
We used to return `int` in `getAsInt`, while `IntInit::getValue`
returns `int64_t` and `utohexstr` needs `uint64_t`. The casting
causes the wrong hex value when printing bits value.
Fixing an issue found in a UBsan build. When defining a variable-length
encoding with no operands or slices, the HasDynamicSegment member was
read without being initialised.
This commit:
TableGen: Try to fix expensive checks failures
d2a9b87fee84766b28bd39b46c913da00e1450f4
fixed one of the sort() calls, but there's another.
Caught on expensive-checks buildbots that started to fail sporadically
after submitting
[AMDGPU] Add True16 register classes.
469b3bfad20550968ac428738eb1f8bb8ce3e96d
Doxygen documentation takes very long to build, when making releases we
want to get the normal documentation up earlier so that we don't have to
wait for doxygen documentation.
This PR just adds the flag to disable doxygen builds, I will then later
make a PR that changes the actions to first build the normal docs and
another job to build the doxygen docs.
I landed this format helper, but unfortunately, it didn't work because
of permissions, it could not add comments on a fork's PR. @cor3ntin
informed me there are fixes for this that you had worked on @tstellar -
but I didn't have time to read up on it too much. Can you explain what
changes are needed to get the action to be able to write comments on
fork's PR?
sync_source_lists_from_cmake.py checks that every unittest in CMake
also exists in the GN build. 4f330b7f756e added VETests, but the GN
build doesn't include the VE target. So add a dummy target for this
to placate the check.
