aboutsummaryrefslogtreecommitdiff
path: root/contrib/llvm-project
Commit message (Collapse)AuthorAgeFilesLines
* Merge commit 8ac140f39084 from llvm git (by Younan Zhang):Dimitry Andric2025-07-213-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Clang][NFCI] Cleanup the fix for default function argument substitution (#104911) (This is one step towards tweaking `getTemplateInstantiationArgs()` as discussed in https://github.com/llvm/llvm-project/pull/102922) We don't always substitute into default arguments while transforming a function parameter. In that case, we would preserve the uninstantiated expression until after, e.g. building up a CXXDefaultArgExpr and instantiate the expression there. For member function instantiation, this algorithm used to cause a problem in that the default argument of an out-of-line member function specialization couldn't get properly instantiated. This is because, in `getTemplateInstantiationArgs()`, we would give up visiting a function's declaration context if the function is a specialization of a member template. For example, ```cpp template <class T> struct S { template <class U> void f(T = sizeof(T)); }; template <> template <class U> void S<int>::f(int) {} ``` The default argument `sizeof(U)` that lexically appears inside the declaration would be copied to the function declaration in the class template specialization `S<int>`, as well as to the function's out-of-line definition. We use template arguments collected from the out-of-line function definition when substituting into the default arguments. We would therefore give up the traversal after the function, resulting in a single-level template argument of the `f` itself. However the default argument here could still reference the template parameters of the primary template, hence the error. In fact, this is similar to constraint checking in some respects: we actually want the "whole" template arguments relative to the primary template, not those relative to the function definition. So this patch adds another flag to indicate `getTemplateInstantiationArgs()` for that. This patch also consolidates the tests for default arguments and removes some unnecessary tests. This fixes a crash or assertion failure while building tests for the devel/hpx port. PR: 288352 MFC after: 3 days
* contrib/llvm-project: re-add clang/tools/clang-scan-depsDimitry Andric2025-06-253-2/+1098
| | | | | | This is in preparation for adding it as an optional tool in base. MFC after: 1 week
* contrib/llvm-project: fix clang crash compiling modulesLexi Winter2025-06-257-18/+91
| | | | | | | | | | | | | | | clang++ may crash when compiling certain C++20 modules. Backport the fix from LLVM upstream. This fixes LLVM bug 102684: https://github.com/llvm/llvm-project/issues/102684. PR: 287803 MFC after: 3 days Obtained from: https://github.com/llvm/llvm-project/pull/102855 Reviewed by: kevans, dim Approved by: kevans (mentor) Differential Revision: https://reviews.freebsd.org/D51041
* libc++: fix compiling <locale> with -fmodulesJordan Gordeev2025-05-181-1/+7
| | | | | | | | | | | | | | | | | In /usr/include/c++/v1/__locale_dir/locale_base_api.h, xlocale.h is included without first including stdio.h and stdlib.h, which causes functions like strtoll_l() or sscanf_l() to not be declared. When compiling with -fmodules, locale_base_api.h is processed separately due to a declaration in /usr/include/c++/v1/module.modulemap, and this will cause errors due to the above undeclared symbols. Meanwhile, upstream has substantially reorganized this part of libc++'s headers, so apply a minimalistic workaround: specifically when compiling with -fmodules, add includes of stdio.h and stdlib.h. PR: 286342 MFC after: 1 week
* Merge llvm-project release/19.x llvmorg-19.1.7-0-gcd708029e0b2Dimitry Andric2025-01-1618-72/+123
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.7-0-gcd708029e0b2, a.k.a. 19.1.7 release. PR: 280562 MFC after: 3 days
* Merge llvm-project release/19.x llvmorg-19.1.5-0-gab4b5a2db582Dimitry Andric2024-12-0629-101/+210
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.5-0-gab4b5a2db582, a.k.a. 19.1.5 release. PR: 280562 MFC after: 3 days
* Merge llvm-project release/19.x llvmorg-19.1.4-0-gaadaa00de76eDimitry Andric2024-11-2128-253/+355
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.4-0-gaadaa00de76e, a.k.a. 19.1.4 release. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.3-0-gab51eccf88f5Dimitry Andric2024-11-0828-80/+185
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.3-0-gab51eccf88f5, a.k.a. 19.1.3 release. PR: 280562 MFC after: 1 month
* Tentatively merge llvm fix for buildworld WITH_ASANDimitry Andric2024-10-281-1/+1
| | | | | | | | | | | | | | | | | Building world using WITH_ASAN results in an assertion when compiling certain source files referencing ifuncs: Assertion failed: (isa<Function>(Callee) || isa<GlobalAlias>(Callee)), function analyzeAllUses, file /root/freebsd/contrib/llvm-project/llvm/lib/Analysis/StackSafetyAnalysis.cpp, line 514. This was already reported upstream a while ago, in <https://github.com/llvm/llvm-project/issues/87923>, but now there is finally a candidate fix, which seems trivial so I am importing it right away. Reported by: markj PR: 280936 Pull Request: https://github.com/llvm/llvm-project/pull/113841 MFC after: 3 days
* Fix buildworld with gcc 12 after llvm-19 importDimitry Andric2024-10-251-0/+2
| | | | | | | | | | | | | | | | | | | | | Unfortunately gcc 12's is not yet capable of compiling all of libc++ 19's C++23 code, which results in errors similar to: /usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:41:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Iter, _Sent, const _Type&, _Proj)' must be a non-static member function 41 | operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = {}) { | ^~~~~~~~ /usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:48:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Range&&, const _Type&, _Proj)' must be a non-static member function 48 | operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) { | ^~~~~~~~ Until we can get rid of gcc 12, work around this by making it compile libc++ in C++20 mode instead. NOTE: The resulting libc++ library will not be C++23 compatible! Please try to avoid shipping it, and use gcc 13 instead, if you must use gcc. PR: 280562 MFC after: 3 days
* Apply workaround for building llvm-project with WITHOUT_LLVM_ASSERTIONSDimitry Andric2024-10-244-12/+12
| | | | | | | | | | | | | | | | | Some internal checking functions should only be declared when both NDEBUG and LLVM_ENABLE_ABI_BREAKING_CHECKS are undefined, otherwise you would get compile errors similar to: /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:921:13: error: no member named 'VerifyDAGDivergence' in 'llvm::SelectionDAG' 921 | CurDAG->VerifyDAGDivergence(); | ~~~~~~ ^ Adjust the conditions for declaring and using these functions. This has also been reported upstream. Reported by: cy PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6Dimitry Andric2024-10-2330-335/+245
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.2-0-g7ba7d8e2f7b6, a.k.a. 19.1.2 release. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.1-0-gd401987fe349Dimitry Andric2024-10-2333-77/+315
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.1-0-gd401987fe349, a.k.a. 19.1.1 release. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1Dimitry Andric2024-10-2330-175/+225
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-0-ga4bf6cd7cfb1, a.k.a. 19.1.0 release. PR: 280562 MFC after: 1 month
* Merge commit 6dbdb8430b49 from llvm git (by Nikolas Klauser):Dimitry Andric2024-10-231-1/+2
| | | | | | | | | | | | | [Clang] Fix crash due to invalid source location in __is_trivially_equality_comparable (#107815) Fixes #107777 This fixes an assertion failure building www/qt5-webengine: Assertion failed: (Loc.isValid() && "point of instantiation must be valid!"), function setPointOfInstantiation, file contrib/llvm-project/clang/include/clang/AST/DeclTemplate.h, line 1938. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-rc4-0-g0c641568515aDimitry Andric2024-10-2354-271/+405
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-rc4-0-g0c641568515a. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8Dimitry Andric2024-10-23110-1442/+1223
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-rc3-0-g437434df21d8. PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1cDimitry Andric2024-10-2382-689/+1094
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-rc2-0-gd033ae172d1c. PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-4003-g55357160d0e1:Dimitry Andric2024-10-232-13/+13
| | | | | | | | | | | [libc++] Use GCC type traits builtins for remove_cv and remove_cvref (#81386) They have been added recently to GCC without support for mangling. This patch uses them in structs and adds aliases to these structs instead of the builtins directly. PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-4504-g937a5396cf3e:Dimitry Andric2024-10-231-0/+6
| | | | | | | [libc++] Remove unused includes from __type_traits/is_convertible.h (#83747) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-5639-ga10aa4485e83:Dimitry Andric2024-10-233-15/+7
| | | | | | | | | | [libc++] Simplify the implementation of remove_reference (#85207) GCC 13 introduced the type trait `__remove_reference`. We can simplify the implementation of `remove_reference` a bit by using it. PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-8667-g472b612ccbed:Dimitry Andric2024-10-232-1/+2
| | | | | | | [libc++][NFC] Remove unused includes from <__type_traits/remove_cv.h> (#88752) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-17473-g69fecaa1a455:Dimitry Andric2024-10-2310-31/+266
| | | | | | | [libc++] Clean up some now dead code with the upgrade to GCC 14 (#97746) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-17727-g0eebb48fcfbc:Dimitry Andric2024-10-236-13/+68
| | | | | | | | | | [libc++] Merge is_member{,_object,_function}_pointer.h (#98727) The implementations for these traits have been simplified quite a bit, since we have builtins available for them now. PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-17728-g30cc12cd818d:Dimitry Andric2024-10-233-5/+11
| | | | | | | [libc++] Simplify the implementation of is_null_pointer a bit (#98728) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-17853-g578c6191eff7:Dimitry Andric2024-10-231-2/+18
| | | | | | | [libc++] Simplify std::is_void (#99033) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-18062-g4dfa75c663e5:Dimitry Andric2024-10-234-10/+38
| | | | | | | [libc++] Merge is_scoped_enum.h into is_enum.h (#99458) PR: 280562 MFC after: 1 month
* libcxx-compat: revert llvmorg-19-init-18063-g561246e90282:Dimitry Andric2024-10-231-1/+1
| | | | | | | [libc++][NFC] Remove wrong #endif comment PR: 280562 MFC after: 1 month
* libcxx cstdlib, cwchar: avoid using long long functions if notDimitry Andric2024-10-232-0/+16
| | | | | | | | supported, even for older compilers that do not support the using_if_exists attribute. PR: 280562 MFC after: 1 month
* libcxx atomic_ref.h: add typename keyword for difference_typeDimitry Andric2024-10-231-2/+2
| | | | | | | declarations, otherwise older clang versions cannot compile this header. PR: 280562 MFC after: 1 month
* libcxx simd_utils.h: only enable _LIBCPP_HAS_ALGORITHM_VECTOR_UTILS forDimitry Andric2024-10-231-1/+1
| | | | | | | clang >= 15, since older versions do not support the required builtins. PR: 280562 MFC after: 1 month
* Tentatively apply https://github.com/llvm/llvm-project/pull/101403Dimitry Andric2024-10-233-3/+3
| | | | | PR: 280562 MFC after: 1 month
* Merge llvm-project release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2Dimitry Andric2024-10-2378-321/+768
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/19.x llvmorg-19.1.0-rc1-0-ga4902a36d5c2. PR: 280562 MFC after: 1 month
* Merge llvm-project main llvmorg-19-init-18630-gf2ccf80136a0Dimitry Andric2024-10-235747-218816/+421501
| | | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project main llvmorg-19-init-18630-gf2ccf80136a0, the last commit before the upstream release/19.x branch was created. PR: 280562 MFC after: 1 month
* Merge commit b84d773fd004 from llvm git (by Fangrui Song):Dimitry Andric2024-09-223-61/+48
| | | | | | | | | | | | | | | | | | | | | | | | | [Parallel] Revert sequential task changes https://reviews.llvm.org/D148728 introduced `bool Sequential` to unify `execute` and the old `spawn` without argument. However, sequential tasks might be executed by any worker thread (non-deterministic), leading to non-determinism output for ld.lld -z nocombreloc (see https://reviews.llvm.org/D133003). In addition, the extra member variables have overhead. This sequential task has only been used for lld parallel relocation scanning. This patch restores the behavior before https://reviews.llvm.org/D148728 . Fix #105958 Pull Request: https://github.com/llvm/llvm-project/pull/109084 This fixes the non-reproducibility we had noticed when linking our EFI loaders, and for which we committed a workaround in f5ce3f4ef562. MFC after: 3 days
* Merge commit d2353ae00c3b from llvm git (by Argyrios Kyrtzidis):Dimitry Andric2024-08-101-3/+3
| | | | | | | | | | | | | | | | | | | | [utils/TableGen/X86CompressEVEXTablesEmitter.cpp] Make sure the tablegen output for the `checkPredicate` function is deterministic (#84533) The output for the `checkPredicate` function was depending on a `std::map` iteration that was non-deterministic from run to run, because the keys were pointer values. Make a change so that the keys are `StringRef`s so the ordering is stable. This avoids non-determinism in llvm-tblgen output, which could cause differences in the generated X86GenCompressEVEXTables.inc file. Although these differences are not influencing the meaning of the generated code, they still change a few bytes in libllvm. This in turn influences all the binaries linked with libllvm, such as clang, ld.lld, etc. Reported by: cperciva MFC after: 3 days
* Merge commit cb7a03b41fff from llvm git (by Nikolas Klauser):John Baldwin2024-08-053-1/+9
| | | | | | | | | [libc++] Fix failures with GCC 14 (#92663) Fixes #91831 Reviewed by: dim Differential Revision: https://reviews.freebsd.org/D46003
* Merge commit c80c09f3e380 from llvm-project (by Dimitry Andric):Dimitry Andric2024-07-282-5/+14
| | | | | | | | | | | | | | | | | | | | | | [CalcSpillWeights] Avoid x87 excess precision influencing weight result Fixes #99396 The result of `VirtRegAuxInfo::weightCalcHelper` can be influenced by x87 excess precision, which can result in slightly different register choices when the compiler is hosted on x86_64 or i386. This leads to different object file output when cross-compiling to i386, or native. Similar to 7af3432e22b0, we need to add a `volatile` qualifier to the local `Weight` variable to force it onto the stack, and avoid the excess precision. Define `stack_float_t` in `MathExtras.h` for this purpose, and use it. This is the version of the fix for PR276961 that landed upstream. PR: 276961 Reported by: cperciva MFC after: 3 days
* Revert "Fix llvm register allocator for native/cross build differences"Dimitry Andric2024-07-281-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for applying the fix that landed upstream, this reverts commit 397c2693fa66508cb5e6b173650a1f3bc6c4dd4f: Fix llvm register allocator for native/cross build differences Work around an issue in LLVM's register allocator, which can cause slightly different i386 object files, when produced by a native or cross build of clang. This adds another volatile qualifier to a float variable declaration in the weightCalcHelper() function, which otherwise produces slightly different float results on amd64 and i386 hosts. In turn, this can lead to different (but equivalent) register choices, and thus non-identical assembly code. See https://github.com/llvm/llvm-project/issues/99396 for more details. Note this is a temporary fix, meant to merge in time for 13.4. As soon as upstream has a permanent solution we will import that. PR: 276961 Reported by: cperciva MFC after: 3 days
* Merge commit 28a2b85602a5 from llvm-project (by Kazu Hirata):Dimitry Andric2024-07-251-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [DeadStoreElimination] Use SmallSetVector (NFC) (#79410) The use of SmallSetVector saves 0.58% of heap allocations during the compilation of a large preprocessed file, namely X86ISelLowering.cpp, for the X86 target. During the experiment, the final size of ToCheck was 8 or less 88% of the time. Merge commit 9e95c4947d31 from llvm-project (by Nikita Popov): [DSE] Fix non-determinism due to address reuse (#84943) The malloc->calloc fold creates a new MemoryAccess, which may end of at the same address as a previously deleted access inside SkipStores. To the most part, this is not a problem, because SkipStores is normally only used together with MemDefs. Neither the old malloc access nor the new calloc access will be part of MemDefs, so there is no problem here. However, SkipStores is also used in one more place: In the main DSE loop, ToCheck entries are checked against it. Fix this by not using SkipStores here, and instead using a separate set to track deletions inside this loop. This way it is not affected by the calloc optimization that happens outside it. This is all pretty ugly, but I haven't found another good way to fix it. Suggestions welcome. No test case as I don't have a reliable DSE-only test-case for this. Fixes https://github.com/llvm/llvm-project/issues/84458. This fixes another possible difference in output when building i386 object files with a native or cross build of clang. (Specifically, the file sbin/ipf/ipmon/ipmon.o.) PR: 276961 Reported by: cperciva MFC after: 3 days
* Fix llvm register allocator for native/cross build differencesDimitry Andric2024-07-211-1/+6
| | | | | | | | | | | | | | | | | | | | | Work around an issue in LLVM's register allocator, which can cause slightly different i386 object files, when produced by a native or cross build of clang. This adds another volatile qualifier to a float variable declaration in the weightCalcHelper() function, which otherwise produces slightly different float results on amd64 and i386 hosts. In turn, this can lead to different (but equivalent) register choices, and thus non-identical assembly code. See https://github.com/llvm/llvm-project/issues/99396 for more details. Note this is a temporary fix, meant to merge in time for 13.4. As soon as upstream has a permanent solution we will import that. PR: 276961 Reported by: cperciva MFC after: 3 days
* Merge commit 382f70a877f0 from llvm-project (by Louis Dionne):Dimitry Andric2024-06-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [libc++][NFC] Rewrite function call on two lines for clarity (#79141) Previously, there was a ternary conditional with a less-than comparison appearing inside a template argument, which was really confusing because of the <...> of the function template. This patch rewrites the same statement on two lines for clarity. Merge commit d129ea8d2fa3 from llvm-project (by Vitaly Buka): [libcxx] Align `__recommend() + 1` by __endian_factor (#90292) This is detected by asan after #83774 Allocation size will be divided by `__endian_factor` before storing. If it's not aligned, we will not be able to recover allocation size to pass into `__alloc_traits::deallocate`. we have code like this ``` auto __allocation = std::__allocate_at_least(__alloc(), __recommend(__sz) + 1); __p = __allocation.ptr; __set_long_cap(__allocation.count); void __set_long_cap(size_type __s) _NOEXCEPT { __r_.first().__l.__cap_ = __s / __endian_factor; __r_.first().__l.__is_long_ = true; } size_type __get_long_cap() const _NOEXCEPT { return __r_.first().__l.__cap_ * __endian_factor; } inline ~basic_string() { __annotate_delete(); if (__is_long()) __alloc_traits::deallocate(__alloc(), __get_long_pointer(), __get_long_cap()); } ``` 1. __recommend() -> even size 2. `std::__allocate_at_least(__alloc(), __recommend(__sz) + 1)` - > not even size 3. ` __set_long_cap() `- > lose one bit of size for __endian_factor == 2 (see `/ __endian_factor`) 4. `__alloc_traits::deallocate(__alloc(), __get_long_pointer(), __get_long_cap())` -> uses even size (see `__get_long_cap`) This should fix incorrect deallocation sizes for some instances of std::string. Memory profiling or debugging tools like AddressSanitizer, LeakSanitizer or TCMalloc could then complain about the the size passed to a deallocation not matching the size originally passed to the allocation. Reported by: Aliaksei Kandratsenka <alkondratenko@gmail.com> PR: 279560 MFC after: 3 days
* Merge commit 9f85bc834b07 from llvm-project (by Nikita Popov):Dimitry Andric2024-05-301-30/+7
| | | | | | | | | | | | | | | | | | | | | [PPCMergeStringPool] Only replace constant once (#92996) In #88846 I changed this code to use RAUW to perform the replacement instead of manual updates -- but kept the outer loop, which means we try to perform RAUW once per user. However, some of the users might be freed by the RAUW operation, resulting in use-after-free. The case where this happens is constant users where the replacement might result in the destruction of the original constant. Fixes https://github.com/llvm/llvm-project/issues/92991. This fixes a possible crash when building crypto/openssh/sshkey.c for PowerPC targets. Reported by: cperciva PR: 276104 MFC after: 3 days
* Merge commit d0be944aa511 from llvm-project (by Simon Pilgrim):Dimitry Andric2024-05-251-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | [X86] Add slow div64 tuning flag to Nehalem target (#91129) This appears to have been missed because later cpus don't inherit from Nehalem tuning much. Noticed while cleaning up for #90985 Merge commit 8b400de79eff from llvm-project (by Simon Pilgrim): [X86] Enable TuningSlowDivide64 on Barcelona/Bobcat/Bulldozer/Ryzen Families (#91277) Despite most AMD cpus having a lower latency for i64 divisions that converge early, we are still better off testing for values representable as i32 and performing a i32 division if possible. All AMD cpus appear to have been missed when we added the "idivq-to-divl" attribute - this patch now matches Intel cpu behaviour (and the x86-64/v2/3/4 levels). Unfortunately the difference in code scheduling means I've had to stop using the update_llc_test_checks script and just use old-fashioned CHECK-DAG checks for divl/divq pairs. Fixes #90985 This fixes possibly worse runtime performance on AMD Zen hardware, when using -march=znver4 (or any other znver), as opposed to -march=x86-64-v4 or the baseline -march=x86-64. A similar fix is applied for Nehalem. PR: 278908 MFC after: 3 days
* Merge llvm-project release/18.x llvmorg-18.1.6-0-g1118c2e05e67Dimitry Andric2024-05-2439-154/+301
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/18.x llvmorg-18.1.6-0-g1118c2e05e67. PR: 276104 MFC after: 3 days
* Merge commit 87f3407856e6 from llvm-project (by Phoebe Wang):Dimitry Andric2024-05-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [X86][Driver] Do not add `-evex512` for `-march=native` when the target doesn't support AVX512 (#91694) This prevents problems with ports that fail to build with CPUTYPE=native, if the native CPU supports AVX512F, resulting in errors like: /wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_template.h:197:21: error: always_inline function '_mm512_set1_epi8' requires target feature 'evex512', but would be inlined into function 'adler32_x86_avx512_vl512_vnni' that is compiled without support for 'evex512' 197 | const vec_t ones = VSET1_8(1); | ^ /wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_template.h:116:23: note: expanded from macro 'VSET1_8' 116 | # define VSET1_8(a) _mm512_set1_epi8(a) | ^ /wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_template.h:197:21: error: AVX vector return of type '__m512i' (vector of 8 'long long' values) without 'evex512' enabled changes the ABI /wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_template.h:116:23: note: expanded from macro 'VSET1_8' 116 | # define VSET1_8(a) _mm512_set1_epi8(a) | ^ Ports known to be affected are: archivers/libdeflate, devel/highway, www/node20, and lang/rust. (For rust itself there is also a similar issue reported at https://github.com/rust-lang/rust/pull/121088). PR: 276104 Reported by: netchild MFC after: 3 days
* Merge commit 73bb8d9d92f6 from llvm-project (by Jonathan Peyton):Dimitry Andric2024-05-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | [OpenMP] Fix child processes to use affinity_none (#91391) When a child process is forked with OpenMP already initialized, the child process resets its affinity mask and sets proc-bind-var to false so that the entire original affinity mask is used. This patch corrects an issue with the affinity initialization code setting affinity to compact instead of none for this special case of forked children. The test trying to catch this only testing explicit setting of KMP_AFFINITY=none. Add test run for no KMP_AFFINITY setting. Fixes: #91098 This should fix OpenMP processes sometimes getting stuck on a single CPU core. PR: 278845 Reported by: Cassidy B. Larson <cbl@cbl.us> MFC after: 3 days
* Merge commit 5300a6731e98 from llvm-project (by Jonathan Peyton):Dimitry Andric2024-05-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [OpenMP] Fix re-locking hang found in issue 86684 (#88539) This was initially reported here (including stacktraces): https://stackoverflow.com/questions/78183545/does-compiling-imagick-with-openmp-enabled-in-freebsd-13-2-cause-sched-yield If `__kmp_register_library_startup()` detects that another instance of the library is present, `__kmp_is_address_mapped()` is eventually called. which uses `kmpc_alloc()` to allocate memory. This function calls `__kmp_entry_thread()` to access the thread-local memory pool, which is a bad idea during initialization. This macro internally calls `__kmp_get_global_thread_id_reg()` which sets the bootstrap lock at the beginning (before calling `__kmp_register_library_startup()`). The fix is to use `KMP_INTERNAL_MALLOC()`/`KMP_INTERNAL_FREE()` instead of `kmpc_malloc()`/`kmpc_free()`. `KMP_INTERNAL_MALLOC` and `KMP_INTERNAL_FREE` do not use any bootstrap locks. They just translate to `malloc()`/`free()` and are meant to be used during library initialization before other library-specific allocators have been initialized. Fixes: #86684 This should fix OpenMP processes sometimes getting locked with 100% CPU usage, endlessly calling sched_yield(2). PR: 278845 Reported by: Cassidy B. Larson <cbl@cbl.us> MFC after: 3 days
* Merge llvm-project release/18.x llvmorg-18.1.5-0-g617a15a9eac9Dimitry Andric2024-05-0427-128/+200
| | | | | | | | This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp to llvm-project release/18.x llvmorg-18.1.5-0-g617a15a9eac9. PR: 276104 MFC after: 3 days
* Merge commit 0f329e0246d1 from llvm-project (by Dimitry Andric):Dimitry Andric2024-04-252-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [sanitizer_symbolizer] Cast arguments for format strings in markup (#89815) When compiling the common sanitizer libraries, there are many warnings about format specifiers, similar to: compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp:31:32: warning: format specifies type 'void *' but the argument has type 'uptr' (aka 'unsigned long') [-Wformat] 31 | buffer->AppendF(kFormatData, DI->start); | ~~~~~~~~~~~ ^~~~~~~~~ compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup_constants.h:33:46: note: format string is defined here 33 | constexpr const char *kFormatData = "{{{data:%p}}}"; | ^~ | %lu compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp:46:43: warning: format specifies type 'void *' but the argument has type 'uptr' (aka 'unsigned long') [-Wformat] 46 | buffer->AppendF(kFormatFrame, frame_no, address); | ~~~~~~~~~~~~ ^~~~~~~ compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup_constants.h:36:48: note: format string is defined here 36 | constexpr const char *kFormatFrame = "{{{bt:%u:%p}}}"; | ^~ | %lu ... This is because `uptr` is dependent on the platform, and can be either `unsigned long long`, `unsigned long`, or `unsigned int`. To fix the warnings, cast the arguments to the expected type of the format strings. PR: 276104 Reported by: pstef MFC after: 3 days
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-17 22:28:36 +0000