Update LLVM to version 18.1.4 #37
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
To relax scanning record, tweak order by `Decision < Expansion`, or `Expansion` could not be distinguished whether it belonged to `Decision` or not. Relevant to #77871 (cherry picked from commit 438fe1d)
The current implementation (D138849) assumes `Branch`(es) would follow after the corresponding `Decision`. It is not true if `Branch`(es) are forwarded to expanded file ID. As a result, consecutive `Decision`(s) would be confused with insufficient number of `Branch`(es). `Expansion` will point `Branch`(es) in other file IDs if `Expansion` is included in the range of `Decision`. Fixes #77871 --------- Co-authored-by: Alan Phipps <[email protected]> (cherry picked from commit d912f1f)
Prior to 885d7b7, the builtins library contained two chkstk implementations for each of i386 and x86_64, one that was used in mingw environments, and one unused (with a symbol name not matching anything that is used anywhere). Some of the functions additionally had other, also unused, aliases. After cleaning this up in 885d7b7, the unused symbol names were removed. At the same time, symbol aliases were added for the names as they are used by MSVC; the functions are functionally equivalent, but have different names between mingw and MSVC style environments. By adding a symbol alias (so that one object file contains two different symbols for the same function), users can run into problems with duplicate definitions, if they themselves define one of the symbols (for various reasons), but need to link in the other one. This happens for Wine, which provides their own definition of "__chkstk", but when built in mingw mode does need compiler-rt to provide the mingw specific symbol names; see mstorsjo/llvm-mingw#397. To avoid the issue, remove the extra MS style names. They weren't entirely usable as such for MSVC style environments anyway, as compiler-rt builtins don't build these object files at all, when built in MSVC mode; thus, the effort to provide them for MSVC style environments in 885d7b7 was a half-hearted step towards that. If we really do want to provide those functions (as an alternative to the ones provided by MSVC itself), we should do it in a separate object file (even if the function implementation is the same), so that users who have a definition of one of them but need a definition of the other, won't have conflicts. Additionally, if we do want to provide them for MSVC, those files actually should be built when building the builtins in MSVC mode as well (see compiler-rt/lib/builtins/CMakeLists.txt). If we do that, there's a risk that an MSVC style build ends up linking in and preferring our implementation over the one provided by MSVC, which would be suboptimal. Our implementation always probes the requested amount of stack, while the MSVC one checks the amount of allocated stack and only probes as much as really is needed. In short - this reverts the situation to what it was in the 17.x release series (except for unused functions that have been removed). (cherry picked from commit 248aeac)
This allows caching AA queries both within and across the calls, and enables us to use a custom AAQI configuration. (cherry picked from commit 89dae79)
(cherry picked from commit 7143b45)
JumpThreading may perform AA queries while the dominator tree is not up to date, which may result in miscompilations. Fix this by adding a new AAQI option to disable the use of the dominator tree in BasicAA. Fixes llvm/llvm-project#79175. (cherry picked from commit 4f32f5d)
This adds GCC-compatible names for code model selection on 64-bit SPARC with absolute code. Testing with a 2-stage build then running codegen tests works okay under all of the supported code models. (32-bit target does not have selectable code models) Reviewed By: @brad0, @MaskRay (cherry picked from commit b0f0bab)
Fixes #80366 (cherry picked from commit 4e958ab)
We noticed that some feature-test macros were not conditional on configuration flags like _LIBCPP_HAS_NO_FILESYSTEM. As a result, code attempting to use FTMs would not work as intended. This patch adds conditionals for a few feature-test macros, but more issues may exist. rdar://122020466 (cherry picked from commit f2c8421)
…(#80661) As of 4d20cfc, `__bit_reference` contains a template `__fill_n` with a bool `_FillValue` parameter. Unfortunately there is a relatively widely used piece of scientific software called NetCDF, which exposes a (C) macro `_FillValue` in its public headers. When building the NetCDF C++ bindings, this quickly leads to compilation errors when the macro interferes with the template in `__bit_reference`. Rename the parameter to `_FillVal` to avoid the conflict. (cherry picked from commit 1ec2522)
This enables IR expansion for i128 divisions. The vector case is still broken because ExpandLargeDivRem doesn't try to handle them. Fixes: SWDEV-426193 (cherry picked from commit a5d206d)
…file data (#78879)
The new CLANG_PGO_TRAINING_DATA_SOURCE_DIR allows users to specify a
CMake project to use for generating the profile data. For example, to
use the llvm-test-suite to generate profile data you would do:
$ cmake -G Ninja -B build -S llvm -C <path to
source>/clang/cmake/caches/PGO.cmake \
-DBOOTSTRAP_CLANG_PGO_TRAINING_DATA_SOURCE_DIR=<path to llvm-test-suite>
\
-DBOOTSTRAP_CLANG_PGO_TRAINING_DEPS=runtimes
Note that the CLANG_PERF_TRAINING_DEPS has been renamed to
CLANG_PGO_TRAINING_DEPS.
---------
Co-authored-by: Petr Hosek <[email protected]>
(cherry picked from commit dd0356d)
Background: BPI stores a collection of edge branch-probabilities, and also a set of Callback value-handles for the blocks in the edge-collection. When a block is deleted, BPI's eraseBlock method is called to clear the edge-collection of references to that block, to avoid dangling pointers. However, when move-constructing or assigning a BPI object, the edge-collection gets moved, but the value-handles are discarded. This can lead to to stale entries in the edge-collection when blocks are deleted without the callback -- not normally a problem, but if a new block is allocated with the same address as an old block, spurious branch probabilities will be recorded about it. The fix is to transfer the handles from the source BPI object. This was exposed by an unrelated debug-info change, it probably just shifted around allocation orders to expose this. Detected as nondeterminism and reduced by Zequan Wu: llvm/llvm-project@f1b0a54#commitcomment-136737090 (No test because IMHO testing for a behaviour that varies with memory allocators is likely futile; I can add the reproducer with a CHECK for the relevant branch weights if it's desired though) (cherry picked from commit 604a6c4)
The assertion in #80597 failed when we were trying to compute known bits of a value in an unreachable BB. https://github.com/llvm/llvm-project/blob/859b09da08c2a47026ba0a7d2f21b7dca705864d/llvm/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp#L749-L810 In this case, `SignBits` is 30 (deduced from instr info), but `Known` is `10000101010111010011110101000?0?00000000000000000000000000000000` (deduced from dom cond). Setting high bits of `lshr Known, 1` will lead to conflict. This patch masks out high bits of `Known.Zero` to address this problem. Fixes #80597. (cherry picked from commit cb8d83a)
Modifying a cherry-picked patch to fix code formatting issues can be risky, so we don't typically do this. Therefore, it's not necessary to run this job on the release branches. (cherry picked from commit 2193c95)
A recent comment modified the job to only run on the main branch, but the formatting was slightly off, causing the job to not run. This patch fixes the formatting so the job will run as expected. (cherry picked from commit 4b34558)
(cherry picked from commit dd22140)
In llvm/llvm-project#76873 a warning was added when the macros INFINITY and NAN are used in binary expressions when -menable-no-nans or -menable-no-infs are used. If the user uses an option that nullifies these two options, the warning will still be generated. This patch adds an additional information to the warning comment to let the user know about this. It also suppresses the warning when #ifdef INFINITY, #ifdef NAN, #ifdef NAN or #ifndef NAN are used in the code. (cherry picked from commit 62c352e)
FastISel may create a redundant BGTZ terminal which fallthroughes. ``` BGTZ %2:gpr32, %bb.1, implicit-def $at bb.1.bb1: ; predecessors: %bb.0 ``` The `!I->isBarrier()` check in MipsAsmPrinter::isBlockOnlyReachableByFallthrough will incorrectly not print a label, leading to a `Undefined temporary symbol ` error when we try assembling the output assembly file. See the updated `Fast-ISel/pr40325.ll` and rust-lang/rust#108835 In addition, the `SwitchInst` condition is too conservative and prints many unneeded labels (see the updated tests). Just use the generic isBlockOnlyReachableByFallthrough, updated by commit 1995b9f for SPARC, which also handles MIPS. (cherry picked from commit 6b2fd7a)
Tests with umin where the result may be poison for llvm/llvm-project#78621. (cherry picked from commit c83180c)
The result of umin may be poison and in that case the added constraints are not be valid in contexts where poison doesn't cause UB. Only queue facts for min/max intrinsics if the result is guaranteed to not be poison. This could be improved in the future, by only adding the fact when solving conditions using the result value. Fixes llvm/llvm-project#78621. (cherry picked from commit 3d91d96)
Change AfterPlacementOperator to a boolean and deprecate SBPO_Never, which meant never inserting a space except when after new/delete. Fixes #78892. (cherry picked from commit 908fd09)
Backporting llvm/llvm-project#79568 to clang 18.
Currently when interleaving vector calls with linear arguments, the Part is ignored and all vector calls use the initial value from the first lane of the current iteration. Fix this to extract from the correct part of the linear vector. (cherry picked from commit d4c0171)
(cherry picked from commit 7c3ee7c)
Currently, the way that recomputeLiveIns works is that it will recompute the livein registers for that MachineBasicBlock but it matters what order you call recomputeLiveIn which can result in incorrect register allocations down the line. Now we do not recompute the entire CFG but we do ensure that the newly added MBB do reach convergence. This fixes a register allocation bug introduced in AArch64 stack probing. (cherry picked from commit ff4636a)
… to 8 (#68925) (#79480) This change saves memory by providing the allocator more freedom to allocate the most efficient size class by dropping the alignment requirements for std::string's pointer from 16 to 8. This changes the output of std::string::max_size, which makes it ABI breaking. That said, the discussion concluded that we don't care about this ABI break. and would like this change enabled universally. The ABI break isn't one of layout or "class size", but rather the value of "max_size()" changes, which in turn changes whether `std::bad_alloc` or `std::length_error` is thrown for large allocations. This change is the child of PR #68807, which enabled the change behind an ABI flag.
In glibc versions before 2.33. `libc_nonshared.a` defines `__fxstat/__fxstat64` but there is no `fstat/fstat64`. glibc 2.33 added `fstat/fstat64` and obsoleted `__fxstat/__fxstat64`. Ports added after 2.33 do not provide `__fxstat/__fxstat64`, so our `fstat/fstat64` interceptors using `__fxstat/__fxstat64` interceptors would lead to runtime failures on such ports (LoongArch and certain RISC-V ports). Similar to https://reviews.llvm.org/D118423, refine the conditions that we define fstat{,64} interceptors. `fstat` is supported by musl/*BSD while `fstat64` is glibc only. (cherry picked from commit d5224b7)
…field (#74512) Shadowing warning doesn't make much sense since field is not available in lambda's body without capturing this. Fixes llvm/llvm-project#71976
The range for these operations is being constructed without the maximum value for the range due to an incorrect usage of the ConstantRange constructor. This causes Float2Int to think the range for 'uitofp i1' only contains 0 instead of 0 and 1. (cherry picked from commit 6295e67)
…041) We were passing the min and max values of the range to the ConstantRange constructor, but the constructor expects the upper bound to 1 more than the max value so we need to add 1. We also need to use getNonEmpty so that passing 0, 0 to the constructor creates a full range rather than an empty range. And passing smin, smax+1 doesn't cause an assertion. I believe this fixes at least some of the reason #79158 was reverted. (cherry picked from commit 1283646)
Even if __need_unreachable is set, stddef.h should not declare unreachable() in C++ because it conflicts with the declaration in \<utility>. (cherry picked from commit df69a30)
Also reformat Polly. Fixes #79834. (cherry picked from commit 8de2300)
Add wheel publishing in addition to existing source distribution publishing of lit. Fixes #63369. This also uses the exact fix proposed by @EFord36 in #63369. Signed-off-by: Schuyler Eldridge <[email protected]> (cherry picked from commit 8a8ab8f)
Libc++'s own <stddef.h> is complicated by the need to handle various platform-specific macros and to support duplicate inclusion. In reality, we only need to add a declaration of nullptr_t to it, so we can simply include the underlying <stddef.h> outside of our guards to let it handle re-inclusion itself. (cherry picked from commit 2950283)
This adds support for using the L and H argument modifiers for twinword
operands in inline asm code, such as in:
```
%1 = tail call i64 asm sideeffect "rd %pc, ${0:L} ; srlx ${0:L}, 32, ${0:H}", "={o4}"()
```
This is needed by the Linux kernel.
(cherry picked from commit 697dd93)
__precision_ is declared as an int32_t which on some hexagon platforms
is defined as a long.
This change fixes errors like the ones below:
In file included from
/local/mnt/workspace/hex/llvm-project/libcxx/test/libcxx/diagnostics/format.nodiscard_extensions.compile.pass.cpp:19:
In file included from
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/format:202:
In file included from
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:29:
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/formatter_floating_point.h:700:17:
error: no matching function for call to 'max'
700 | int __p = std::max(1, (__specs.__has_precision() ?
__specs.__precision_ : 6));
| ^~~~~~~~
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/formatter_floating_point.h:771:25:
note: in instantiation of function template specialization
'std::__formatter::__format_floating_point<float, char,
std::format_context>' requested here
771 | return __formatter::__format_floating_point(__value, __ctx,
__parser_.__get_parsed_std_specifications(__ctx));
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:284:42:
note: in instantiation of function template specialization
'std::__formatter_floating_point<char>::format<float,
std::format_context>' requested here
284 | __ctx.advance_to(__formatter.format(__arg, __ctx));
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:429:15:
note: in instantiation of function template specialization
'std::__vformat_to<std::back_insert_iterator<std::string>, char,
std::back_insert_iterator<std::__format::__output_buffer<char>>>'
requested here
429 | return std::__vformat_to(std::move(__out_it), __fmt, __args);
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:462:8:
note: in instantiation of function template specialization
'std::vformat_to<std::back_insert_iterator<std::string>>' requested here
462 | std::vformat_to(std::back_inserter(__res), __fmt, __args);
| ^
/local/mnt/workspace/hex/llvm-project/libcxx/test/libcxx/diagnostics/format.nodiscard_extensions.compile.pass.cpp:29:8:
note: in instantiation of function template specialization
'std::vformat<void>' requested here
29 | std::vformat("", std::make_format_args());
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:35:1:
note: candidate template ignored: deduced conflicting types for
parameter '_Tp' ('int' vs. 'int32_t' (aka 'long'))
35 | max(_LIBCPP_LIFETIMEBOUND const _Tp& __a, _LIBCPP_LIFETIMEBOUND
const _Tp& __b) {
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:43:1:
note: candidate template ignored: could not match
'initializer_list<_Tp>' against 'int'
43 | max(initializer_list<_Tp> __t, _Compare __comp) {
| ^
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:48:86:
note: candidate function template not viable: requires single argument
'__t', but 2 arguments were provided
48 | _LIBCPP_NODISCARD_EXT inline _LIBCPP_HIDE_FROM_ABI
_LIBCPP_CONSTEXPR_SINCE_CXX14 _Tp max(initializer_list<_Tp> __t) {
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:29:1:
note: candidate function template not viable: requires 3 arguments, but
2 were provided
29 | max(_LIBCPP_LIFETIMEBOUND const _Tp& __a, _LIBCPP_LIFETIMEBOUND
const _Tp& __b, _Compare __comp) {
| ^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(cherry picked from commit e1830f5)
…analysis. Need to support proper type conversion for function arguments to avoid compiler crash.
…7542) While attempting to build some Rust code, I was getting linker errors due to missing functions that are implemented in `compiler-rt`. Turns out that when `compiler-rt` is built for Arm64EC, all its function names are mangled with the leading `#`. This change removes the hard-coded list of library-implemented intrinsics to mangle for Arm64EC, and instead assumes that they all must be mangled.
… in threadBinOpOverSelect (#87075) Alive2: https://alive2.llvm.org/ce/z/y_Jmdn Fix llvm/llvm-project#87042. (cherry picked from commit 3197f9d)
This fixes an edge case where functions starting with inline assembly would assert while trying to lower that inline asm instruction. After this PR, for now we always add a no-op (xchgw in this case) without considering the size of the next inline asm instruction. We might want to revisit this in the future. This fixes Unreal Engine 5.3.2 compilation with clang-cl and /HOTPATCH. Should close llvm/llvm-project#56234 (cherry picked from commit ec1af63)
Register spills (save/restore) in RISC-V embedded work differently because there are less registers and different stack alignment. [GCC equivalent ](https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/riscv/save-restore.S#L298C16-L336) Follow up from #76777. --------- Signed-off-by: xermicus <[email protected]> (cherry picked from commit bd32aaa)
…rryDiamond` (#84888) Fixes #84831 When matching carry pattern with `getAsCarry`, it may produce different type of carryout. This patch checks such case and does early exit. I'm new to DAG, any suggestion is appreciated. (cherry picked from commit cb4453d)
As reported in #86843, we must have #pragma GCC system_header before we use #include_next, otherwise the compiler may not understand that we're in a system header and may issue a diagnostic for our usage of (cherry picked from commit 3c4b673)
When doing GC, we normally won't have dangling references, because such a reference would keep the other section alive, keeping it from being eliminated. However, references within DWARF sections are ignored for the purposes of GC (because otherwise, they would essentially keep everything alive, defeating the point of the GC), see c579a5b for more context. Therefore, dangling relocations against discarded symbols are ignored within DWARF sections (see maybeReportRelocationToDiscarded in Chunks.cpp). Consequently, we also shouldn't create any pseudo relocations for these cases, as we run into a null pointer dereference when trying to generate the pseudo relocation info for it. This fixes the downstream bug mstorsjo/llvm-mingw#418, fixing crashes on combinations with -ffunction-sections, -fdata-sections, -Wl,--gc-sections and debug info. (cherry picked from commit 9c970d5)
…omic max (#77072)" These changes caused correctness regressions observed in Rust, see llvm/llvm-project#77072 (comment). This reverts commit 0e501db. This reverts commit fbb27d1.
Previously, the `override` keyword in C++ was being print in the left side of a method decl, which is unsupported by C++ standard. This commit fixes that by setting the `CanPrintOnLeft` field to 0, forcing it to be print on the right side of the decl. Signed-off-by: Giuliano Belinassi <[email protected]>
- The opcode of the mina.fmt and max.fmt is documented wrong, the
object code compiled from the same assembly with LLVM behaves
differently than one compiled with GCC and Binutils.
- Modify the opcodes to match Binutils. The actual opcodes are as
follows:
{5,3} | bits {2,0} of func
| ... | 100 | 101 | 110 | 111
-----+-----+-----+-----+-----+-----
010 | ... | min | mina | max | maxa
(cherry picked from commit 8b859c6)
Running the test-release.sh script with PGO enabled causes build errors like: ld.lld: error: Function Import: link error: linking module flags 'ProfileSummary': IDs have conflicting values I believe this a build system bug due to the PGO profile data being generated unconditionally. If you run `ninja check-all` and then `ninja install` like we do in test-release.sh, then the profile data is regenerated during `ninja install` and some of the clang tools which are not test dependencies get build during the ninja install step with different profile data. When these tools link against the LLVM libraries, like libSupport, we end up with these errors. (cherry picked from commit 0d2bb7f)
Update LLVM version to 18.0.0
Update LLVM to 18.1.4 version
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Build and testing passed