- 17 Aug, 2022 4 commits
-
-
Fangrui Song authored
release/15.x uses C++14 and structured bindings trigger warnings in Clang/GCC and errors in MSVC.
-
Michał Górny authored
Move the `LLVM_INSTALL_PACKAGE_DIR` declaration from llvm/cmake/modules directory to the top-level llvm/CMakeLists.txt, in order to fix the regression in `llvm-config --cmakedir` output for installed LLVM. Since the tools directory is processed by CMake prior to llvm/cmake/modules, the llvm-config executable ended up using the variable prior to it being defined and incorrectly used an empty path, resulting in e.g.: $ llvm-config --cmakedir /usr/lib/llvm/16/ With this patch, the path is defined (and therefore the default value is being set) prior to adding the tools subdirectory and llvm-config starts working correctly: $ llvm-config --cmakedir /usr/lib/llvm/16/lib64/cmake/llvm This fixes a regression introduced by D130539. Thanks to Petr Polezhaev for reporting the problem @ https://bugs.gentoo.org/865165 Differential Revision: https://reviews.llvm.org/D131878 (cherry picked from commit d2300552)
-
Maciej Gabka authored
arm_sve.h defines and uses __ai macro which needs to be undefined (as it is already in arm_neon.h). Reviewed By: paulwalker-arm Differential Revision: https://reviews.llvm.org/D131580 (cherry picked from commit 48e1250a)
-
David Green authored
This is a followup to D131350, which caused another problem for i64 types being split into i32 on i32 targets. This patch tries to make sure that either Illegal types are OK, or that the element types of a buildvector are legal and bigger than or equal to the size of the original elements. Differential Revision: https://reviews.llvm.org/D131883 (cherry picked from commit dfc95bab)
-
- 16 Aug, 2022 9 commits
-
-
Diana Picus authored
Make sure that FortranDecimal, FortranRuntime and Fortran_main are installed/packaged even when LLVM_INSTALL_TOOLCHAIN_ONLY is enabled. They are used by flang to link executables, so they should be provided even with minimal installs. Differential Revision: https://reviews.llvm.org/D131670 (cherry picked from commit 467abac2)
-
Craig Topper authored
We were incorrectly checking that it returned an implicaton result, not that the implication result itself was true.
-
Fangrui Song authored
`getContext().setMCLineTableRootFile` (from D62074) sets `RootFile.Name` to `FirstCppHashFilename`. `RootFile.Name` is not processed by -fdebug-prefix-map and will go to DW_TAG_compile_unit's DT_AT_name and DW_TAG_label's DW_AT_decl_file. Remap `RootFile.Name`. Fix another issue reported by https://github.com/llvm/llvm-project/issues/56609 Reviewed By: #debug-info, dblaikie, raj.khem Differential Revision: https://reviews.llvm.org/D131848 (cherry picked from commit d797c2ff)
-
Fangrui Song authored
DWARF v5 6.2.4 The Line Number Program Header says: > The first entry is the current directory of the compilation. Each additional > path entry is either a full path name or is relative to the current directory of > the compilation. When forming a path, relative DW_AT_comp_dir and directories[0] are not supposed to be joined together. Fix getFileNameByIndex to special case DWARF v5 DirIdx == 0. Reviewed By: #debug-info, dblaikie Differential Revision: https://reviews.llvm.org/D131804 (cherry picked from commit 3329cec2)
-
Fangrui Song authored
For generated assembly debug info, MCDwarfLineTableHeader::CompilationDir is an unmapped path set in MCContext::setGenDwarfRootFile. Remap it. A relative destination path of -fdebug-prefix-map= exposes a llvm-dwarfdump bug which joins relative DW_AT_comp_dir and directories[0]. Fix https://github.com/llvm/llvm-project/issues/56609 Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D131749 (cherry picked from commit f62e60fb)
-
Fangrui Song authored
(cherry picked from commit 53113515)
-
Fangrui Song authored
(cherry picked from commit d561907f)
-
Fangrui Song authored
(cherry picked from commit b0c4cd35)
-
Peter Waller authored
Discussed in D131503. Fix to D130782. (cherry picked from commit 89869983)
-
- 15 Aug, 2022 15 commits
-
-
Martin Storsjö authored
This release note was added tentatively in https://reviews.llvm.org/D120982 / ebde6fc2. The issue was resolved differently in https://reviews.llvm.org/D125715 / bedf657d, but that commit forgot to remove the tentative release note.
-
Zachary Henkel authored
Found during clang 15 RC1 testing due to the new diagnostic added by @royjacobson since clang 14. Uncertain if this fix meets the bar to also be applied to the release branch. If accepted, I'll need someone with commit access to submit on my behalf. Reviewed By: royjacobson, aaron.ballman, erichkeane Differential Revision: https://reviews.llvm.org/D131730 (cherry picked from commit 64f0f7e6)
-
Phoebe Wang authored
This is to avoid f16->i64 being lowered to `__fixhfdi/__fixunshfdi` on 32-bits since neither libgcc nor compiler-rt provide them. https://godbolt.org/z/cjWEsea5v It also helps to improve the performance by promoting the vector type. Reviewed By: LuoYuanke Differential Revision: https://reviews.llvm.org/D131828 (cherry picked from commit 8b69549d)
-
Phoebe Wang authored
The problem Alexander reported on D127982 was caused by an optimization for AVX512-FP16 instruction. We must limit it to the feature enabled only. During the investigation, I found we didn't expand for fp_round/fp_extend without F16C. This may result runtime crash, so change them too. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D130817 (cherry picked from commit 23021d4d)
-
Vladimir Plyashkun authored
It seems that documentation for abseil-no-internal-dependencies has invalid title. This can be checked by looking at the actual web-site - https://clang.llvm.org/extra/clang-tidy/checks/abseil/no-internal-dependencies.html There is redundant "subl.. title:: clang-tidy - abseil-no-internal-dependencies" paragraph in the beginning. Reviewed By: njames93, sylvestre.ledru Differential Revision: https://reviews.llvm.org/D131590 (cherry picked from commit 6c7b049f)
-
Simon Pilgrim authored
As mentioned on D128934 - we weren't including the CPUID bit handling for the RDPRU instruction AMD's APMv3 (24594) lists it as CPUID Fn8000_0008_EBX Bit#4 (cherry picked from commit 08a88050)
-
Simon Pilgrim authored
These were missed in D128934 (cherry picked from commit 6e19e6ce)
-
Amy Kwan authored
This patch fixes the max_size.pass.cpp test for PowerPC targets, depending on endianness. We will exhibit the full_size() behaviour for little endian (where __endian_factor = 2 ), and the half_size() behaviour for big endian (where __endian_factor = 1). Differential Revision: https://reviews.llvm.org/D131682 (cherry picked from commit e2e9e2ce)
-
Johannes Doerfert authored
The problem is we create the call to __kmpc_kernel_parallel in the openmp-opt pass but while we optimize the code, the call is not there yet. Thus, we assume we never reach it from __kmpc_target_deinit. That allows us to remove the store in there (`ParallelRegionFn = nullptr`), which leads to bad results later on. This is a shortstop solution until we come up with something better. Fixes https://github.com/llvm/llvm-project/issues/57064 (cherry picked from commit a8cda329)
-
Shilei Tian authored
[Clang][OpenMP] Fix the issue that `llvm.lifetime.end` is emitted too early for variables captured in linear clause Currently if an OpenMP program uses `linear` clause, and is compiled with optimization, `llvm.lifetime.end` for variables listed in `linear` clause are emitted too early such that there could still be uses after that. Let's take the following code as example: ``` // loop.c int j; int *u; void loop(int n) { int i; for (i = 0; i < n; ++i) { ++j; u = &j; } } ``` We compile using the command: ``` clang -cc1 -fopenmp-simd -O3 -x c -triple x86_64-apple-darwin10 -emit-llvm loop.c -o loop.ll ``` The following IR (simplified) will be generated: ``` @j = local_unnamed_addr global i32 0, align 4 @u = local_unnamed_addr global ptr null, align 8 define void @loop(i32 noundef %n) local_unnamed_addr { entry: %j = alloca i32, align 4 %cmp = icmp sgt i32 %n, 0 br i1 %cmp, label %simd.if.then, label %simd.if.end simd.if.then: ; preds = %entry call void @llvm.lifetime.start.p0(i64 4, ptr nonnull %j) store ptr %j, ptr @u, align 8 call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j) %0 = load i32, ptr %j, align 4 store i32 %0, ptr @j, align 4 br label %simd.if.end simd.if.end: ; preds = %simd.if.then, %entry ret void } ``` The most important part is: ``` call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j) %0 = load i32, ptr %j, align 4 store i32 %0, ptr @j, align 4 ``` `%j` is still loaded after `@llvm.lifetime.end.p0(i64 4, ptr nonnull %j)`. This could cause the backend incorrectly optimizes the code and further generates incorrect code. The root cause is, when we emit a construct that could have `linear` clause, it usually has the following pattern: ``` EmitOMPLinearClauseInit(S) { OMPPrivateScope LoopScope(*this); ... EmitOMPLinearClause(S, LoopScope); ... (void)LoopScope.Privatize(); ... } EmitOMPLinearClauseFinal(S, [](CodeGenFunction &) { return nullptr; }); ``` Variables that need to be privatized are added into `LoopScope`, which also serves as a RAII object. When `LoopScope` is destructed and if optimization is enabled, a `@llvm.lifetime.end` is also emitted for each privatized variable. However, the writing back to original variables in `linear` clause happens after the scope in `EmitOMPLinearClauseFinal`, causing the issue we see above. A quick "fix" seems to be, moving `EmitOMPLinearClauseFinal` inside the scope. However, it doesn't work. That's because the local variable map has been updated by `LoopScope` such that a variable declaration is mapped to the privatized variable, instead of the actual one. In that way, the following code will be generated: ``` %0 = load i32, ptr %j, align 4 store i32 %0, ptr %j, align 4 call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j) ``` Well, now the life time is correct, but apparently the writing back is broken. In this patch, a new function `OMPPrivateScope::restoreMap` is added and called before calling `EmitOMPLinearClauseFinal`. This can make sure that `EmitOMPLinearClauseFinal` can find the orignal varaibls to write back. Fixes #56913. Reviewed By: ABataev Differential Revision: https://reviews.llvm.org/D131272 (cherry picked from commit e21202da)
-
David Truby authored
The __ARM_FEATURE_SVE_VECTOR_OPERATORS macro should be changed to indicate that this feature is now supported on VLA vectors as well as VLS vectors. There is a complementary PR to the ACLE spec here https://github.com/ARM-software/acle/pull/213 Reviewed By: peterwaller-arm Differential Revision: https://reviews.llvm.org/D131573 (cherry picked from commit 13a784f3)
-
David Truby authored
Previously the table in LanguageExtensions said that sizeof worked on SVE types but this is only correct for fixed-length vectors so a clarification has been added. (cherry picked from commit bbb30bd5)
-
David Truby authored
Previously the language extension documentation didn't mention SVE and was incomplete in listing the C/C++ operators supported on NEON. This corrects the documentation to be in line with the implementation. (cherry picked from commit e4642d78)
-
David Truby authored
This patch enables the unary promotion and negation operators on SVE types. Differential Revision: https://reviews.llvm.org/D130984 (cherry picked from commit 286d59ef)
-
Jennifer Yu authored
https://github.com/llvm/llvm-project/issues/56884 The root problem is in isOpenMPRebuildMemberExpr, it is only need to rebuild for field expression. No need for member function call. The fix is to check field for member expression and skip rebuild for member function call. Differential Revision: https://reviews.llvm.org/D131024 (cherry picked from commit a7bca18b)
-
- 12 Aug, 2022 12 commits
-
-
Benjamin Kramer authored
[mlir][sparse] Refine f695554a wording a bit and fix the double conversion I broke with aggressive copy&paste (cherry picked from commit 726719e9)
-
Benjamin Kramer authored
c7ec6e19 made LLVM adhere to the x86 psABI and pass bf16 in SSE registers instead of GPRs. This breaks the custom versions of runtime functions we have for bf16 conversion. A great fix for this would be to use __bf16 types instead which carry the right ABI, but that type isn't widely available. Instead just pretend it's a 32 bit float on the ABI boundary and carefully cast it to the right type. Fixes #57042 (cherry picked from commit f695554a)
-
Aart Bik authored
Supposedly our ABI issues were fixed, per issue: https://github.com/llvm/llvm-project/issues/55992 However, with a recent changes to bf16, these tests fail again; not sure why yet: https://reviews.llvm.org/D130832 https://lab.llvm.org/buildbot/#/builders/61/builds/30600 So we disable the tests for now. Issue is tracked in: https://github.com/llvm/llvm-project/issues/57042 Differential Revision: https://reviews.llvm.org/D131621 (cherry picked from commit 6b745911)
-
Phoebe Wang authored
Differential Revision: https://reviews.llvm.org/D131147 (cherry picked from commit f061cfb3)
-
Freddy Ye authored
X86 psABI has updated to support __bf16 type, the ABI of which is the same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149 Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D130964 (cherry picked from commit e4888a37)
-
Phoebe Wang authored
X86 psABI has updated to support __bf16 type, the ABI of which is the same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149 This is an alternative of D129858, which has less code modification and supports the vector type as well. Reviewed By: LuoYuanke Differential Revision: https://reviews.llvm.org/D130832 (cherry picked from commit c7ec6e19)
-
Martin Storsjö authored
This is an entirely new embedded directive - extending the GNU ld command line option --exclude-symbols to be usable in embedded directives too. (GNU ld.bfd also got support for the same new directive, currently in the latest git version, after the 2.39 branch.) This works as an inverse to the regular embedded dllexport directives, for cases when autoexport of all eligible symbols is performed. Differential Revision: https://reviews.llvm.org/D130120 (cherry picked from commit 5d513ef6)
-
Fangrui Song authored
The former stores strings and is therefore more expensive. (cherry picked from commit dfe2a3f3)
-
Martin Storsjö authored
This adds support for the existing GNU ld command line option, which allows excluding individual symbols from autoexport (when linking a DLL and no symbols are marked explicitly as dllexported). Differential Revision: https://reviews.llvm.org/D130118 (cherry picked from commit d1da6469)
-
Martin Storsjö authored
Since bb939931, the c++experimental library is always built, so these tested files should always be built (even if they aren't used in tests). Differential Revision: https://reviews.llvm.org/D129399 (cherry picked from commit b8717d19)
-
Louis Dionne authored
(cherry picked from commit b1009bbd)
-
Louis Dionne authored
This will allow using it in functions that are [[noreturn]] themselves. Differential Revision: https://reviews.llvm.org/D131408 (cherry picked from commit f5738c51)
-