LLVM bump #22
Merged
LLVM bump #22
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
…/shl X, Z)); NFC Differential Revision: https://reviews.llvm.org/D143013
…X, Z))`
We can handle the following cases + some `nsw`/`nuw` flags:
`(srem (mul X, Y), (mul X, Z))`
[If `srem(Y, Z) == 0`]
-> 0
- https://alive2.llvm.org/ce/z/PW4XZ-
[If `srem(Y, Z) == Y`]
-> `(mul nuw nsw X, Y)`
- https://alive2.llvm.org/ce/z/DQe9Ek
-> `(mul nsw X, Y)`
- https://alive2.llvm.org/ce/z/Nr_MdH
[If `Y`/`Z` are constant]
-> `(mul/shl nuw nsw X, (srem Y, Z))`
- https://alive2.llvm.org/ce/z/ccTFj2
- https://alive2.llvm.org/ce/z/i_UQ5A
-> `(mul/shl nsw X, (srem Y, Z))`
- https://alive2.llvm.org/ce/z/mQKc63
- https://alive2.llvm.org/ce/z/uERkKH
`(urem (mul X, Y), (mul X, Z))`
[If `urem(Y, Z) == 0`]
-> 0
- https://alive2.llvm.org/ce/z/LL7UVR
[If `srem(Y, Z) == Y`]
-> `(mul nuw nsw X, Y)`
- https://alive2.llvm.org/ce/z/9Kgs_i
-> `(mul nuw X, Y)`
- https://alive2.llvm.org/ce/z/ow9i8u
[If `Y`/`Z` are constant]
-> `(mul nuw nsw X, (srem Y, Z))`
- https://alive2.llvm.org/ce/z/mNnQqJ
- https://alive2.llvm.org/ce/z/Bj_DR-
- https://alive2.llvm.org/ce/z/X6ZEtQ
-> `(mul nuw X, (srem Y, Z))`
- https://alive2.llvm.org/ce/z/SJYtUV
The rationale for doing this all in `InstCombine` rather than handling
the constant `mul` cases in `InstSimplify` is we often create a new
instruction because we are able to deduce more `nsw`/`nuw` flags than
the original instruction had.
Reviewed By: MattDevereau, sdesmalen
Differential Revision: https://reviews.llvm.org/D143014
This addresses the issue found by: https://lab.llvm.org/buildbot/#/builders/30/builds/33006
Differential Revision: https://reviews.llvm.org/D146249
… on the heap The previous code resulted in 252 KiB being allocated on the stack, which caused a stack overflow on Fuchsia. Reviewed By: Chia-hungDuan Differential Revision: https://reviews.llvm.org/D146229
…ltiple fragments in case of SROA The function transferSRADebugInfo is modified to include missing cases. Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D138992
…he environment variable. Using two environment variables `CC_PRINT_INTERNAL_STAT` and `CC_PRINT_INTERNAL_STAT_FILE` to work like `CC_PRINT_PROC_STAT`. The purpose of the change is to allow collecting the internal stats without modifying the build scripts. Write all stats to a single file to simplify aggregating the data. Differential Revision: https://reviews.llvm.org/D144981
Fixes build w/ GCC 13:
```
[587/7274] Building CXX object projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o
FAILED: projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o
/usr/lib/llvm/16/bin/clang++ -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/sam/git/llvm-project/build/projects/libc/test/src/__support -I/home/sam/git/llvm-project/libc/test/src/__support -I/home/sam/git/llvm-project/build/include -I/home/sam/git/llvm-project/llvm/include -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -g -std=c++17 -MD -MT projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o -MF projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o.d -o projects/libc/test/src/__support/CMakeFiles/libc_system_str_to_float_comparison_test.dir/str_to_float_comparison_test.cpp.o -c /home/sam/git/llvm-project/libc/test/src/__support/str_to_float_comparison_test.cpp
/home/sam/git/llvm-project/libc/test/src/__support/str_to_float_comparison_test.cpp:34:15: error: unknown type name 'uint32_t'
static inline uint32_t hexCharToU32(char in) {
^
/home/sam/git/llvm-project/libc/test/src/__support/str_to_float_comparison_test.cpp:39:15: error: unknown type name 'uint32_t'
static inline uint32_t fastHexToU32(const char *inStr) {
^
```
Reviewed By: michaelrj
Differential Revision: https://reviews.llvm.org/D146111
…ions with no stack frame Summary: In function PPCAIXAsmPrinter::emitTracebackTable() ,the bit "IsBackChainStored" of traceback table always set true, it will cause aix debug tools "dbx" emit an error info "libdebug assertion "(framep->getGpr(STKP, &addr) == DB_SUCCESS && *nextStkpp == addr)" when debug a leaf functions with no stack frame. If a a leaf functions with no stack frame , the bit IsBackChainStored should be unset. Reviewers: ChenZheng Differential Revision: https://reviews.llvm.org/D146071
This patch fixes: mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp:479:13: error: unused variable 'tiledOp' [-Werror,-Wunused-variable]
Reviewed By: wrengr Differential Revision: https://reviews.llvm.org/D146248
…uction-based codegen Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D142927
The patch fixes "Virtual register does not match instruction constraint" and partly "Illegal virtual register for instruction" fails in the SPIRV backend builds with LLVM_ENABLE_EXPENSIVE_CHECKS enabled. As a result, the number of passed LIT tests with enabled checks is doubled. Also, support for ndrange_*D builtins is placed in a separate function. Differential Revision: https://reviews.llvm.org/D144897
There are 2 such base cases: indirect calls and calls to functions external to the module; and then any musttail calls to live functions (because of the first 2 reasons or otherwise). The IR validator reports, in these cases, that it "cannot guarantee tail call due to mismatched parameter counts". The fix is two-fold: first, we mark as "live" (i.e. non-DAE-able) functions that make an indirect musttail call. Then, we propagate live-ness to musttail callers of live functions. Declared functions are already marked "live". Differential Revision: https://reviews.llvm.org/D145209
This greatly reduces the number of allocators we create, while still retaining thread safety. Reducing the number of allocators is much better for locality and memory usage; this revision drops memory usage for some MLIR heavy workloads (with lots of attributes/types) by >=5%. This is due to the observation that the number of threads is effectively always smaller than the number of parametric attributes/types. Differential Revision: https://reviews.llvm.org/D145991
…ebug-only" option. This should fix the test failure in Release builds.
This field is never used in the compiler and was only used in unit tests added recently. It's only used as the value in a map where the extension name is the key. If we need the string we can get it from the key. Reviewed By: asb Differential Revision: https://reviews.llvm.org/D146197
MemoryCache::Read is not resilient to partial reads when reading memory chunks less than or equal in size to L2 cache lines. There have been attempts in the past to fix this but nothing really solved the root of the issue. I first created a test exercising MemoryCache's implementation and documenting how I believe MemoryCache::Read should behave. I then rewrote the implementation of MemoryCache::Read as needed to make sure that the different scenarios behaved correctly. rdar://105407095 Differential Revision: https://reviews.llvm.org/D145624
Clang infers framework autolink hints when parsing a modulemap. In order to do so, it checks if the module is a framework and if there is a framework binary or TBD file in the SDK. Only when Clang finds the filei, then the autolink hint is added to the module metadata. During a project build many clang processes perform this check, which causes many stat calls - even for modules/frameworks that are not even used. The linker is already resilient to non-existing framework links that come from the autolink metadata, so there is no need for Clang to do this check. Instead the autolink hints are now added unconditionally and the linker only needs to do the check once. This reduces the overall number of stat calls. This fixes rdar://106578342. Differential Revision: https://reviews.llvm.org/D146255
macOS cmp requires the option to appear before the file names.
Change the internal storage scheme from storing a MutableArrayRef to storing an explicit offset+length pair. Storing an ArrayRef is dangerous because it contains the pointer to the first element in the range, but the entire storage vector may be reallocated, making the pointer dangling. We don't know when the reallocation happends, so we can't update the ArrayRefs. Store the explicit offset instead and construct ArrayRefs on-the-fly. Reviewed By: Peiming Differential Revision: https://reviews.llvm.org/D146239
The intent of the code was to reserve all AGPRs on a target without AGPRs, so just do exactly that. Existing code was unsound.
This mostly keeps the same warning flags. The most important exceptions are `-Wpedantic` and `-Wconversion`, which are now removed from libc++abi and libunwind. Reviewed By: ldionne, #libunwind, #libc, #libc_abi Spies: mikhail.ramalho, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D144252
It's possible for `getCalleeDecl()` to return a null pointer. This was encountered by a user of our downstream compiler. The case involved a DependentScopeDeclRefExpr. Since this seems to only be for a warning diagnostic, I skipped the diagnostic check if it returned null. But mabye there's a different way to fix this. Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D146089
Update the code to collect the initializer when collecting the types for a global, as suggested by @nikic in D144476. This replaces code which bailed out if *any* part doesn't have an initializer with a continue to just skip parts which don't have an initializer. Depends on D145489. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D145490
Back in D128714, we should have replaced the old rule about colons when we added the new one. Because we didn't, all colons got mistaken as case colons as long as the line began with `case` or `default`. Now we remove the rule that we forgot to remove. Reviewed By: MyDeveloperDay, rymiel Differential Revision: https://reviews.llvm.org/D145888
- `intrinsic-pointer-to-any.td` - `intrinsic-varargs.td` They used their own mock. I have introduced `TEST_INTRINSICS_SUPPRESS_DEFS` in `Intrinsics.td`. Tests of intrinsics may use it. Differential Revision: https://reviews.llvm.org/D146147
Simplifies the process of building an LLJIT instance that supports the native platform features (initializers, TLV, etc.). SetUpExecutorNativePlatform can be passed to LLJITBuilder::setPlatformSetUp method. It takes a reference to the ORC runtime (as a path or an in-memory archive) and automatically sets the platform for LLJIT's ExecutionSession based on the executor process's triple. Differential Revision: https://reviews.llvm.org/D144276
This reverts commit f890f01.
…d behavior" This reverts commit b6a0be8.
This reverts commit bdf5f9c, which was a work in progress for https://reviews.llvm.org/D144276 and accidentally committed early.
…l pipeline Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D145196
…re correct ordering Branch operands are different from regular instructions. They can have a mix of boolean values and branch instructions. This makes sure that branches are treated as more of a special case and makes sure that the successor blocks are always in the same order, and that they do not include the conditional argument. Reviewer: paquette Differential Revision: https://reviews.llvm.org/D139337
… table. Update JITDylib's symbol table entry struct to use the newer ExecutorAddr type.
Close llvm#38554 Close llvm#58532 It looks like we can workaround the '#pragma once' problem automatically after we force the lazily loading for named modules. Add a test to show this.
Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D146353
Despite the fact that it is legal, it is not profitable. It may prevent Loop Guard Widening to happen. Because of bug described at llvm#60234, now the guard widening is only possible when condtion we want to add is available at the point of the widenable_condition() of dominating guard. It means that, if all such calls are hoisted out of loop, and the loop conditions depend on loop-variants, we cannot widen. Hoisting is otherwise not helpful, because it does not introduce any optimization opportunities. Differential Revision: https://reviews.llvm.org/D146274 Reviewed By: apilipenko
There is a piece of logic in GuardWidening which is very limited, and it happens to ignore implicit control flow, therefore it "works fine" with guards expressed as intrinsic calls. However, when the guards are represented as branches, its limitations create a lot of trouble. The intent here is to make sure that we do not widen code across complex CFG, so that it can end up being in hotter code than it used to be. The old logic was limited to unique immediate successor and that's it. This patch changes the logic there to work the following way: when we need to check if we can widen from `DominatedBlock` into `DominatingBlock`, we first try to find the lowest (by CFG) transitive successor of `DominatingBlock` which is guaranteed to not be significantly colder than the `DominatingBlock`. It means that every time we move to either: - Unique successor of the current block, if it only has one successor; - The only taken successor, if the current block ends with `br(const)`; - If one of successors ends with deopt, another one is taken; If the lowest block we can find this way is the `DominatedBlock`, then it is safe to assume that this widening won't move the code into a hotter location. I did not touch the existing check with PDT. It looks fishy to me (post-dominance doesn't really guarantee anything about hotness), but let's keep it as is and maybe fix later. With this patch, Guard Widening can widen explicitly expressed branches across more than one dominating guard if it's profitable. Differential Revision: https://reviews.llvm.org/D146276 Reviewed By: skatkov
…lding Table 1. Align ManualMapSet with X86MemoryFoldTableEntry instead of using UnfoldStrategy 2. ManualMapSet able to update the existing record in auto-generated MemFold table Reviewed By: skan Differential Revision: https://reviews.llvm.org/D142084
… '>'" This reverts commit b05dc1b. Makes clang-format crash on `struct Foo { operator enum foo{} };`
…ode" This reverts commit 22c3ba4. Breaks buildbot https://lab.llvm.org/buildbot/#/builders/197/builds/4272 Differential Revision: https://reviews.llvm.org/D145551
This revisions refactors the implementation of mapping to threads to additionally allow warps and linear ids to be specified. `warp_dims` is currently specified along with `block_dims` as a transform attribute. Linear ids on th other hand use the flattened block_dims to predicate on the first (linearized) k threads. An additional GPULinearIdMappingAttr is added to the GPU dialect to allow specifying loops mapped to this new scheme. Various implementation and transform op semantics cleanups are also applied. Reviewed By: ThomasRaoux Differential Revision: https://reviews.llvm.org/D146130
This reverts commit c1888a3 because of massive buildbolt failures.
`AllocatableInitIntrinsic`, `AllocatableInitCharacter` and `AllocatableInitDerived` are meant to be used to initialize a descriptor when it is instantiated and not to be used multiple times in a scope. Add `AllocatableInitDerivedForAllocate`, `AllocatableInitCharacterForAllocate` and `AllocatableInitDerivedForAllocate` to be used for the allocation in allocate statement. These new functions are meant to be used on an initialized descriptor and will return directly if the descriptor is allocated so the error handling is done by the call to `AllocatableAllocate`. Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D146290
…functions Update lowering of allocate statement to use the new functions defined in D146290. Depends on D146290 Reviewed By: PeteSteinfeld Differential Revision: https://reviews.llvm.org/D146291
…-1406.bump_llvm_to_green_commit
mgehre-amd
pushed a commit
that referenced
this pull request
Feb 27, 2024
…lvm#80904)" This reverts commit b1ac052. This commit breaks coroutine splitting for non-swift calling convention functions. In this example: ```ll ; ModuleID = 'repro.ll' source_filename = "stdlib/test/runtime/test_llcl.mojo" target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @0 = internal constant { i32, i32 } { i32 trunc (i64 sub (i64 ptrtoint (ptr @craSH to i64), i64 ptrtoint (ptr getelementptr inbounds ({ i32, i32 }, ptr @0, i32 0, i32 1) to i64)) to i32), i32 64 } define dso_local void @af_suspend_fn(ptr %0, i64 %1, ptr %2) #0 { ret void } define dso_local void @craSH(ptr %0) #0 { %2 = call token @llvm.coro.id.async(i32 64, i32 8, i32 0, ptr @0) %3 = call ptr @llvm.coro.begin(token %2, ptr null) %4 = getelementptr inbounds { ptr, { ptr, ptr }, i64, { ptr, i1 }, i64, i64 }, ptr poison, i32 0, i32 0 %5 = call ptr @llvm.coro.async.resume() store ptr %5, ptr %4, align 8 %6 = call { ptr, ptr, ptr } (i32, ptr, ptr, ...) @llvm.coro.suspend.async.sl_p0p0p0s(i32 0, ptr %5, ptr @ctxt_proj_fn, ptr @af_suspend_fn, ptr poison, i64 -1, ptr poison) ret void } define dso_local ptr @ctxt_proj_fn(ptr %0) #0 { ret ptr %0 } ; Function Attrs: nomerge nounwind declare { ptr, ptr, ptr } @llvm.coro.suspend.async.sl_p0p0p0s(i32, ptr, ptr, ...) #1 ; Function Attrs: nounwind declare token @llvm.coro.id.async(i32, i32, i32, ptr) #2 ; Function Attrs: nounwind declare ptr @llvm.coro.begin(token, ptr writeonly) #2 ; Function Attrs: nomerge nounwind declare ptr @llvm.coro.async.resume() #1 attributes #0 = { "target-features"="+adx,+aes,+avx,+avx2,+bmi,+bmi2,+clflushopt,+clwb,+clzero,+crc32,+cx16,+cx8,+f16c,+fma,+fsgsbase,+fxsr,+invpcid,+lzcnt,+mmx,+movbe,+mwaitx,+pclmul,+pku,+popcnt,+prfchw,+rdpid,+rdpru,+rdrnd,+rdseed,+sahf,+sha,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+sse4a,+ssse3,+vaes,+vpclmulqdq,+wbnoinvd,+x87,+xsave,+xsavec,+xsaveopt,+xsaves" } attributes #1 = { nomerge nounwind } attributes #2 = { nounwind } ``` This verifier crashes after the `coro-split` pass with ``` cannot guarantee tail call due to mismatched parameter counts musttail call void @af_suspend_fn(ptr poison, i64 -1, ptr poison) LLVM ERROR: Broken function PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: opt ../../../reduced.ll -O0 #0 0x00007f1d89645c0e __interceptor_backtrace.part.0 /build/gcc-11-XeT9lY/gcc-11-11.4.0/build/x86_64-linux-gnu/libsanitizer/asan/../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:4193:28 #1 0x0000556d94d254f7 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/Unix/Signals.inc:723:22 #2 0x0000556d94d19a2f llvm::sys::RunSignalHandlers() /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/Signals.cpp:105:20 #3 0x0000556d94d1aa42 SignalHandler(int) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/Unix/Signals.inc:371:36 #4 0x00007f1d88e42520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520) #5 0x00007f1d88e969fc __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #6 0x00007f1d88e969fc __pthread_kill_internal ./nptl/pthread_kill.c:78:10 #7 0x00007f1d88e969fc pthread_kill ./nptl/pthread_kill.c:89:10 #8 0x00007f1d88e42476 gsignal ./signal/../sysdeps/posix/raise.c:27:6 #9 0x00007f1d88e287f3 abort ./stdlib/abort.c:81:7 #10 0x0000556d8944be01 std::vector<llvm::json::Value, std::allocator<llvm::json::Value>>::size() const /usr/include/c++/11/bits/stl_vector.h:919:40 #11 0x0000556d8944be01 bool std::operator==<llvm::json::Value, std::allocator<llvm::json::Value>>(std::vector<llvm::json::Value, std::allocator<llvm::json::Value>> const&, std::vector<llvm::json::Value, std::allocator<llvm::json::Value>> const&) /usr/include/c++/11/bits/stl_vector.h:1893:23 #12 0x0000556d8944be01 llvm::json::operator==(llvm::json::Array const&, llvm::json::Array const&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/Support/JSON.h:572:69 #13 0x0000556d8944be01 llvm::json::operator==(llvm::json::Value const&, llvm::json::Value const&) (.cold) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/JSON.cpp:204:28 #14 0x0000556d949ed2bd llvm::report_fatal_error(char const*, bool) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Support/ErrorHandling.cpp:82:70 #15 0x0000556d8e37e876 llvm::SmallVectorBase<unsigned int>::size() const /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallVector.h:91:32 #16 0x0000556d8e37e876 llvm::SmallVectorTemplateCommon<llvm::DiagnosticInfoOptimizationBase::Argument, void>::end() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallVector.h:282:41 #17 0x0000556d8e37e876 llvm::SmallVector<llvm::DiagnosticInfoOptimizationBase::Argument, 4u>::~SmallVector() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallVector.h:1215:24 #18 0x0000556d8e37e876 llvm::DiagnosticInfoOptimizationBase::~DiagnosticInfoOptimizationBase() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/DiagnosticInfo.h:413:7 #19 0x0000556d8e37e876 llvm::DiagnosticInfoIROptimization::~DiagnosticInfoIROptimization() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/DiagnosticInfo.h:622:7 #20 0x0000556d8e37e876 llvm::OptimizationRemark::~OptimizationRemark() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/DiagnosticInfo.h:689:7 #21 0x0000556d8e37e876 operator() /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Transforms/Coroutines/CoroSplit.cpp:2213:14 #22 0x0000556d8e37e876 emit<llvm::CoroSplitPass::run(llvm::LazyCallGraph::SCC&, llvm::CGSCCAnalysisManager&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&)::<lambda()> > /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/Analysis/OptimizationRemarkEmitter.h:83:12 #23 0x0000556d8e37e876 llvm::CoroSplitPass::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Transforms/Coroutines/CoroSplit.cpp:2212:13 #24 0x0000556d8c36ecb1 llvm::detail::PassModel<llvm::LazyCallGraph::SCC, llvm::CoroSplitPass, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 #25 0x0000556d91c1a84f llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Analysis/CGSCCPassManager.cpp:90:12 #26 0x0000556d8c3690d1 llvm::detail::PassModel<llvm::LazyCallGraph::SCC, llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 #27 0x0000556d91c2162d llvm::ModuleToPostOrderCGSCCPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Analysis/CGSCCPassManager.cpp:278:18 #28 0x0000556d8c369035 llvm::detail::PassModel<llvm::Module, llvm::ModuleToPostOrderCGSCCPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 #29 0x0000556d9457abc5 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManager.h:247:20 #30 0x0000556d8e30979e llvm::CoroConditionalWrapper::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/lib/Transforms/Coroutines/CoroConditionalWrapper.cpp:19:74 #31 0x0000556d8c365755 llvm::detail::PassModel<llvm::Module, llvm::CoroConditionalWrapper, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManagerInternal.h:91:3 #32 0x0000556d9457abc5 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/PassManager.h:247:20 #33 0x0000556d89818556 llvm::SmallPtrSetImplBase::isSmall() const /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:196:33 #34 0x0000556d89818556 llvm::SmallPtrSetImplBase::~SmallPtrSetImplBase() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:84:17 #35 0x0000556d89818556 llvm::SmallPtrSetImpl<llvm::AnalysisKey*>::~SmallPtrSetImpl() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:321:7 #36 0x0000556d89818556 llvm::SmallPtrSet<llvm::AnalysisKey*, 2u>::~SmallPtrSet() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/ADT/SmallPtrSet.h:427:7 #37 0x0000556d89818556 llvm::PreservedAnalyses::~PreservedAnalyses() /home/ubuntu/modular/third-party/llvm-project/llvm/include/llvm/IR/Analysis.h:109:7 #38 0x0000556d89818556 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::ArrayRef<std::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) /home/ubuntu/modular/third-party/llvm-project/llvm/tools/opt/NewPMDriver.cpp:532:10 #39 0x0000556d897e3939 optMain /home/ubuntu/modular/third-party/llvm-project/llvm/tools/opt/optdriver.cpp:737:27 #40 0x0000556d89455461 main /home/ubuntu/modular/third-party/llvm-project/llvm/tools/opt/opt.cpp:25:33 #41 0x00007f1d88e29d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #42 0x00007f1d88e29e40 call_init ./csu/../csu/libc-start.c:128:20 #43 0x00007f1d88e29e40 __libc_start_main ./csu/../csu/libc-start.c:379:5 #44 0x0000556d897b6335 _start (/home/ubuntu/modular/.derived/third-party/llvm-project/build-relwithdebinfo-asan/bin/opt+0x150c335) Aborted (core dumped)
mgehre-amd
pushed a commit
that referenced
this pull request
Mar 11, 2024
TestCases/Misc/Linux/sigaction.cpp fails because dlsym() may call malloc on failure. And then the wrapped malloc appears to access thread local storage using global dynamic accesses, thus calling ___interceptor___tls_get_addr, before REAL(__tls_get_addr) has been set, so we get a crash inside ___interceptor___tls_get_addr. For example, this can happen when looking up __isoc23_scanf which might not exist in some libcs. Fix this by marking the thread local variable accessed inside the debug checks as "initial-exec", which does not require __tls_get_addr. This is probably a better alternative to llvm#83886. This fixes a different crash but is related to llvm#46204. Backtrace: ``` #0 0x0000000000000000 in ?? () #1 0x00007ffff6a9d89e in ___interceptor___tls_get_addr (arg=0x7ffff6b27be8) at /path/to/llvm/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:2759 #2 0x00007ffff6a46bc6 in __sanitizer::CheckedMutex::LockImpl (this=0x7ffff6b27be8, pc=140737331846066) at /path/to/llvm/compiler-rt/lib/sanitizer_common/sanitizer_mutex.cpp:218 #3 0x00007ffff6a448b2 in __sanitizer::CheckedMutex::Lock (this=0x7ffff6b27be8, this@entry=0x730000000580) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_mutex.h:129 #4 __sanitizer::Mutex::Lock (this=0x7ffff6b27be8, this@entry=0x730000000580) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_mutex.h:167 #5 0x00007ffff6abdbb2 in __sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock (mu=0x730000000580, this=<optimized out>) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_mutex.h:383 #6 __sanitizer::SizeClassAllocator64<__tsan::AP64>::GetFromAllocator (this=0x7ffff7487dc0 <__tsan::allocator_placeholder>, stat=stat@entry=0x7ffff570db68, class_id=11, chunks=chunks@entry=0x7ffff5702cc8, n_chunks=n_chunks@entry=128) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_allocator_primary64.h:207 #7 0x00007ffff6abdaa0 in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__tsan::AP64> >::Refill (this=<optimized out>, c=c@entry=0x7ffff5702cb8, allocator=<optimized out>, class_id=<optimized out>) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_allocator_local_cache.h:103 #8 0x00007ffff6abd731 in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__tsan::AP64> >::Allocate (this=0x7ffff6b27be8, allocator=0x7ffff5702cc8, class_id=140737311157448) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_allocator_local_cache.h:39 #9 0x00007ffff6abc397 in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__tsan::AP64>, __sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate (this=0x7ffff5702cc8, cache=0x7ffff6b27be8, size=<optimized out>, size@entry=175, alignment=alignment@entry=16) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_allocator_combined.h:69 #10 0x00007ffff6abaa6a in __tsan::user_alloc_internal (thr=0x7ffff7ebd980, pc=140737331499943, sz=sz@entry=175, align=align@entry=16, signal=true) at /path/to/llvm/compiler-rt/lib/tsan/rtl/tsan_mman.cpp:198 #11 0x00007ffff6abb0d1 in __tsan::user_alloc (thr=0x7ffff6b27be8, pc=140737331846066, sz=11, sz@entry=175) at /path/to/llvm/compiler-rt/lib/tsan/rtl/tsan_mman.cpp:223 #12 0x00007ffff6a693b5 in ___interceptor_malloc (size=175) at /path/to/llvm/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:666 #13 0x00007ffff7fce7f2 in malloc (size=175) at ../include/rtld-malloc.h:56 #14 __GI__dl_exception_create_format (exception=exception@entry=0x7fffffffd0d0, objname=0x7ffff7fc3550 "/path/to/llvm/compiler-rt/cmake-build-all-sanitizers/lib/linux/libclang_rt.tsan-x86_64.so", fmt=fmt@entry=0x7ffff7ff2db9 "undefined symbol: %s%s%s") at ./elf/dl-exception.c:157 #15 0x00007ffff7fd50e8 in _dl_lookup_symbol_x (undef_name=0x7ffff6af868b "__isoc23_scanf", undef_map=<optimized out>, ref=0x7fffffffd148, symbol_scope=<optimized out>, version=<optimized out>, type_class=0, flags=2, skip_map=0x7ffff7fc35e0) at ./elf/dl-lookup.c:793 --Type <RET> for more, q to quit, c to continue without paging-- #16 0x00007ffff656d6ed in do_sym (handle=<optimized out>, name=0x7ffff6af868b "__isoc23_scanf", who=0x7ffff6a3bb84 <__interception::InterceptFunction(char const*, unsigned long*, unsigned long, unsigned long)+36>, vers=vers@entry=0x0, flags=flags@entry=2) at ./elf/dl-sym.c:146 #17 0x00007ffff656d9dd in _dl_sym (handle=<optimized out>, name=<optimized out>, who=<optimized out>) at ./elf/dl-sym.c:195 #18 0x00007ffff64a2854 in dlsym_doit (a=a@entry=0x7fffffffd3b0) at ./dlfcn/dlsym.c:40 #19 0x00007ffff7fcc489 in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffd310, operate=0x7ffff64a2840 <dlsym_doit>, args=0x7fffffffd3b0) at ./elf/dl-catch.c:237 #20 0x00007ffff7fcc5af in _dl_catch_error (objname=0x7fffffffd368, errstring=0x7fffffffd370, mallocedp=0x7fffffffd367, operate=<optimized out>, args=<optimized out>) at ./elf/dl-catch.c:256 #21 0x00007ffff64a2257 in _dlerror_run (operate=operate@entry=0x7ffff64a2840 <dlsym_doit>, args=args@entry=0x7fffffffd3b0) at ./dlfcn/dlerror.c:138 #22 0x00007ffff64a28e5 in dlsym_implementation (dl_caller=<optimized out>, name=<optimized out>, handle=<optimized out>) at ./dlfcn/dlsym.c:54 #23 ___dlsym (handle=<optimized out>, name=<optimized out>) at ./dlfcn/dlsym.c:68 #24 0x00007ffff6a3bb84 in __interception::GetFuncAddr (name=0x7ffff6af868b "__isoc23_scanf", trampoline=140737311157448) at /path/to/llvm/compiler-rt/lib/interception/interception_linux.cpp:42 #25 __interception::InterceptFunction (name=0x7ffff6af868b "__isoc23_scanf", ptr_to_real=0x7ffff74850e8 <__interception::real___isoc23_scanf>, func=11, trampoline=140737311157448) at /path/to/llvm/compiler-rt/lib/interception/interception_linux.cpp:61 #26 0x00007ffff6a9f2d9 in InitializeCommonInterceptors () at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_common_interceptors.inc:10315 ``` Reviewed By: vitalybuka, MaskRay Pull Request: llvm#83890
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.
Merges max.FXML-1406.bump_llvm_to_green_commit
fyi @TinaAMD