Backport 13.0.1 to release_13x #97
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
This patches fixes https://bugs.llvm.org/show_bug.cgi?id=51404 Some builds use custom resource directory for clang, therefore the test cannot assume default resource directory for clang. Use -resource-dir to force it. Differential Revision: https://reviews.llvm.org/D111726 (cherry picked from commit 1439df0)
…cause C# behaviour to change
LLVM 13.0.0-rc2 shows change of behaviour in enum and interface BraceWrapping (likely before we simply didn't wrap) but may be related to {D99840}
Logged as https://bugs.llvm.org/show_bug.cgi?id=51640
This change ensure AfterEnum works for
`internal|public|protected|private enum A {` in the same way as it works for `enum A {` in C++
A similar issue was also observed with `interface` in C#
Reviewed By: krasimir, owenpan
Differential Revision: https://reviews.llvm.org/D108810
(cherry picked from commit ed367b9)
In 395271a, I simplified how we handled the target triple for the runtimes. However, in doing so, we stopped considering the default in CMAKE_CXX_COMPILER_TARGET, so we'd use the LLVM_DEFAULT_TARGET_TRIPLE (which is the host triple) even if CMAKE_CXX_COMPILER_TARGET was specified. This commit fixes that problem and also refactors the code so that it's easy to see what the default value is. The fact that nobody seems to have been broken by this makes me think that perhaps nobody is using CMAKE_CXX_COMPILER_TARGET to specify the triple -- but it should still work. Differential Revision: https://reviews.llvm.org/D111672 (cherry picked from commit 72117f2)
`[[clang::fallthrough]]` has meaning for the CFG, but all other StmtAttrs we currently have don't. So omit them, as AttributedStatements with children cause several issues and there's no benefit in including them. Fixes PR52103 and PR49454. See PR52103 for details. Differential Revision: https://reviews.llvm.org/D111568 (cherry picked from commit c74ab84)
Most archs have switched to lld. (cherry picked from commit 89f0587)
The MIPS ABI requires the thread pointer be accessed via rdhwr $3, $r29. This is currently represented by (CopyToReg $3, (RDHWR $29)) followed by a (CopyFromReg $3). However, there is no glue between these, meaning scheduling can break those apart. In particular, PR51691 is a report where PseudoSELECT_I was moved to between the CopyToReg and CopyFromReg, and since its expansion uses branches, it split the def and use of the physical register between two basic blocks, resulting in the def being eliminated and the use having no def. It also seems possible that a similar situation could arise splitting up the CopyToReg from the RDHWR, causing the RDHWR to use a destination register other than $3, violating the ABI requirement. Thus, add glue between all three nodes to ensure they aren't split up during instruction selection. No regression test is added since any test would be implictly relying on specific scheduling behaviour, so whilst it might be testing that glue is preventing reordering today, changes to scheduling behaviour could result in the test no longer being able to catch a regression here, as the reordering might no longer happen for other unrelated reasons. Fixes PR51691. Reviewed By: atanasyan, dim Differential Revision: https://reviews.llvm.org/D111967 (cherry picked from commit f5755c0)
The mips-specific includes have been unnecessary ever since the __clear_cache() builtin replaced cacheflush(). Differential Revision: https://reviews.llvm.org/D111486 (cherry picked from commit a5de04d)
Otherwise we may end up with an inconsistent redeclarations of the standard library functions if _FORTIFY_SOURCE is in effect. https://bugs.llvm.org/show_bug.cgi?id=47869 Differential Revision: https://reviews.llvm.org/D110781 (cherry picked from commit 29e00b2)
bug 51926 identified an issue where a dangling comma caused the cell count to be to off by one Differential Revision: https://reviews.llvm.org/D110481 (cherry picked from commit a36227c)
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D110377 (cherry picked from commit 05c21f5)
The hand-rolled linking logic in elf_common does not account for the possibility of using LLVM dylib rather than a dozen static libraries. Since it does not seem to be easily convertible to add_llvm_library, just hand-roll support for LLVM_LINK_LLVM_DYLIB. This is necessary to support stand-alone builds against installed LLVM. Differential Revision: https://reviews.llvm.org/D111038 (cherry picked from commit 0873b9b)
As reported in Bugzilla 51859, the JitListener/multiple.ll test had become stale. The function order in the emitted image was changed by an update to the MC/ElfObjectWriter code and because this test is disabled by default, it wasn't updated. (cherry picked from commit e49c0c5)
This patch re-introduces the fix in the commit llvm/llvm-project@66b0cebf7f736 by @yrnkrn > In DwarfEHPrepare, after all passes are run, RewindFunction may be a dangling > > pointer to a dead function. To make sure it's valid, doFinalization nullptrs > RewindFunction just like the constructor and so it will be found on next run. > > llvm-svn: 217737 It seems that the fix was not migrated to `DwarfEHPrepareLegacyPass`. This patch also updates `llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` to include `-run-twice` to exercise the cleanup. Without this patch `llvm-lit -v llvm/test/CodeGen/X86/dwarf-eh-prepare.ll` fails with ``` -- Testing: 1 tests, 1 workers -- FAIL: LLVM :: CodeGen/X86/dwarf-eh-prepare.ll (1 of 1) ******************** TEST 'LLVM :: CodeGen/X86/dwarf-eh-prepare.ll' FAILED ******************** Script: -- : 'RUN: at line 1'; /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice < /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -S | /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- Exit Code: 2 Command Output (stderr): -- Referencing function in another module! call void @_Unwind_Resume(i8* %ehptr) flang-compiler#1 ; ModuleID = '<stdin>' void (i8*)* @_Unwind_Resume ; ModuleID = '<stdin>' in function simple_cleanup_catch LLVM ERROR: Broken function found, compilation aborted! PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/arakaki/build/llvm-project/main/bin/opt -mtriple=x86_64-linux-gnu -dwarfehprepare -simplifycfg-require-and-preserve-domtree=1 -run-twice -S 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Running pass 'Module Verifier' on function '@simple_cleanup_catch' #0 0x000056121b570a2c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:569:0 flang-compiler#1 0x000056121b56eb64 llvm::sys::RunSignalHandlers() /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Signals.cpp:97:0 flang-compiler#2 0x000056121b56f28e SignalHandler(int) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/Unix/Signals.inc:397:0 flang-compiler#3 0x00007fc7e9b22980 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12980) flang-compiler#4 0x00007fc7e87d3fb7 raise /build/glibc-S7xCS9/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0 flang-compiler#5 0x00007fc7e87d5921 abort /build/glibc-S7xCS9/glibc-2.27/stdlib/abort.c:81:0 flang-compiler#6 0x000056121b4e1386 llvm::raw_svector_ostream::raw_svector_ostream(llvm::SmallVectorImpl<char>&) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:674:0 flang-compiler#7 0x000056121b4e1386 llvm::report_fatal_error(llvm::Twine const&, bool) /home/arakaki/repos/watch/llvm-project/llvm/lib/Support/ErrorHandling.cpp:114:0 flang-compiler#8 0x000056121b4e1528 (/home/arakaki/build/llvm-project/main/bin/opt+0x29e3528) flang-compiler#9 0x000056121adfd03f llvm::raw_ostream::operator<<(llvm::StringRef) /home/arakaki/repos/watch/llvm-project/llvm/include/llvm/Support/raw_ostream.h:218:0 FileCheck error: '<stdin>' is empty. FileCheck command line: /home/arakaki/build/llvm-project/main/bin/FileCheck /home/arakaki/repos/watch/llvm-project/llvm/test/CodeGen/X86/dwarf-eh-prepare.ll -- ******************** ******************** Failed Tests (1): LLVM :: CodeGen/X86/dwarf-eh-prepare.ll Testing Time: 0.22s Failed: 1 ``` Reviewed By: loladiro Differential Revision: https://reviews.llvm.org/D110979 (cherry picked from commit e8806d7)
Neither the current C++2b draft, nor any revision of [p1135], nor libstdc++, claims that `counting_semaphore` should be default-constructible. I think this was just a copy-paste issue somehow. Also, `explicit` was missing from the constructor. Also, `constexpr` remains missing; but that's probably more of a technical limitation, since apparently there are some platforms where we don't (can't??) use the atomic implementation and have to rely on pthreads, which obviously isn't constexpr. Differential Revision: https://reviews.llvm.org/D110042 (cherry picked from commit c9af0e6)
These can't be made constexpr-constructible (constinit'able), so they aren't C++20-conforming. Also, the platform versions are going to be bigger than the atomic/futex version, so we'd have the awkward situation that `semaphore<42>` could be bigger than `semaphore<43>`, and that's just silly. Differential Revision: https://reviews.llvm.org/D110110 (cherry picked from commit d0eaf75) CHERRY-PICK NOTE BY @ldionne: I added a release note mentioning the ABI break.
Before this patch, `try_acquire` blocks instead of returning false. This is because `__libcpp_thread_poll_with_backoff` interprets zero as meaning infinite, causing `try_acquire` to wait indefinitely. Thanks to Pablo Busse (pabusse) for the patch! Differential Revision: https://reviews.llvm.org/D98334 (cherry picked from commit c92a253)
In ARM mode, passing -mtp=cp15 forces the use of an inline MRC system register read to move the thread pointer value into a register. Currently, in Thumb2 mode, -mtp=cp15 is ignored, and a call to the __aeabi_read_tp helper is emitted instead. This is inconsistent, and breaks the Linux/ARM build for Thumb2 targets, as the Linux kernel does not provide an implementation of __aeabi_read_tp,. Reviewed By: nickdesaulniers, peter.smith Differential Revision: https://reviews.llvm.org/D112600 (cherry picked from commit d7e089f)
The C11 atomics part was wrong. (cherry picked from commit 95e6e1c)
…helpful message instead of broken runtime Differential Revision: https://reviews.llvm.org/D110483 (cherry picked from commit c3aed0d)
Fixes: https://bugs.llvm.org/show_bug.cgi?id=52380 Differential Revision: https://reviews.llvm.org/D112990 (cherry picked from commit c502902)
IIUC we can't emit `memcmp` between pointers in addressspaces, doing so will trigger an assertion since the signature of the memcmp will not match it's arguments (https://bugs.llvm.org/show_bug.cgi?id=48661). This PR disables the attempt to merge icmps, when the pointer is in an addressspace. Reviewed By: #julialang, vtjnash Differential Revision: https://reviews.llvm.org/D94813 (cherry picked from commit 4cacb5c)
This constrains the Mov* and similar pseudo instruction to take GPR64common register classes rather than GPR64. GPR64 includs XZR which is invalid here, because this pseudo instructions expands into an adrp/add pair sharing a destination register. XZR is invalid on add and attempting to encode it will instead increment the stack pointer causing crashes (downstream report at [1]). The test case there reproduces on LLVM11, but I do not have a test case that reaches this code path on main, since it is being masked by improved dead code elimination introduced in D91513. Nevertheless, this seems like a good thing to fix in case there are other cases that dead code elimination doesn't clean up (e.g. if `optnone` is used and the optimization is skipped). I think it would be worth auditing uses of GPR64 in pseudo instructions to see if there are any similar issues, but I do not have a high enough view of the backend or knowledge of the Aarch64 architecture to do this quickly. [1] JuliaLang/julia#39818 Reviewed By: t.p.northover Differential Revision: https://reviews.llvm.org/D97435 (cherry picked from commit e20f69f)
pointers. (cherry picked from commit 173dd89)
… wrong memory location
We see that it might otherwise do:
%10 = getelementptr {}**, <2 x {}***> %9, <2 x i32> <i32 10, i32 4>
%11 = bitcast <2 x {}***> %10 to <2 x i64*>
...
%27 = extractelement <2 x i64*> %11, i32 0
%28 = bitcast i64* %27 to <2 x i64>*
store <2 x i64> %22, <2 x i64>* %28, align 4, !tbaa !2
Which is an out-of-bounds store (the extractelement got offset 10
instead of offset 4 as intended). With the fix, we correctly generate
extractelement for i32 1 and generate correct code.
Differential Revision: https://reviews.llvm.org/D106613
(cherry picked from commit e27a6db)
This pseudo is expanded very late (AsmPrinter) and therefore has to have a correct size value, or the branch relaxation pass may make a wrong decision. Review: Ulrich Weigand (cherry picked from commit 12b44bf)
…nk across VASTART_SAVE_XMM_REGS The changes in D80163 defered the assignment of MachineMemOperand (MMO) until the X86ExpandPseudo pass. This will result in crash due to prolog insert point been sunk across the pseudo instruction VASTART_SAVE_XMM_REGS. Moving the assignment to the creation of the node can avoid the problem. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D112859
As reported in https://bugs.freebsd.org/260078, the gnutls Makefiles pass -Wa,-march=all to compile a number of assembly files. Clang does not support this -march value, but because of a mistake in handling the arguments, an unitialized Arg pointer is dereferenced, which can cause a segfault. Work around this by adding a check if the local WaMArch variable is initialized, and if so, using its value in the diagnostic message. Reviewed By: tschuett Differential Revision: https://reviews.llvm.org/D114677 (cherry picked from commit df08b2f)
… added. rdar://84674985 (cherry picked from commit 5dd9e01)
…CTION_ENTER/FENTRL_CALL MachineOutliner may outline a "patchable-function-entry" function whose body has a TargetOpcode::PATCHABLE_FUNCTION_ENTER MachineInstr. This is incorrect because the special code sequence must stay unchanged to be used at run-time. Avoid outlining PATCHABLE_FUNCTION_ENTER. While here, avoid outlining FENTRY_CALL too (which doesn't reproduce currently) to allow phase ordering flexibility. Fixes #52635 Reviewed By: paquette Differential Revision: https://reviews.llvm.org/D115614 (cherry picked from commit a6a07a5)
Pre-commiting the test case before the bug fix. Reviewed by: Florian Hahn Differential revision: https://reviews.llvm.org/D115965 (cherry picked from commit df59056)
Fix handling of alloc-like instructions in isGuaranteedLoopInvariant(). It was not valid when the 'KillingDef' was outside of the loop, while the 'CurrentDef' was inside the loop. In that case, the 'KillingDef' only overwrites the definition from the last iteration of the loop, and not the ones of all iterations. Therefor it does not make the 'CurrentDef' to be dead, and must not remove it. Fixing issue : llvm/llvm-project#52774 Reviewed by: Florian Hahn Differential revision: https://reviews.llvm.org/D115965 (cherry picked from commit 90d1786)
Changes from commit 1db137b added iteration over hash map that can result in non-deterministic order. Fix that by using a SmallMapVector to preserve the order. Differential Revision: https://reviews.llvm.org/D113468 (cherry picked from commit 3c47c5c)
We have a large compile showing occasional non-deterministic behavior that is due to DIArgList not being properly uniqued in some cases. I tracked this down to handleChangedOperands, for which there is a custom implementation for DIArgList, that does not take care of re-uniquing after updating the DIArgList Args, unlike the default version of handleChangedOperands for MDNode. Since the Args in the DIArgList form the key for the store, this seems to be occasionally breaking the lookup in that DenseSet. Specifically, when invoking DIArgList::get() from replaceVariableLocationOp, very occasionally it returns a new DIArgList object, when one already exists having the same exact Args pointers. This in turn causes a subsequent call to Instruction::isIdenticalToWhenDefined on those two otherwise identical DIArgList objects during a later pass to return false, leading to different IR in those rare cases. I modified DIArgList::handleChangedOperands to perform similar re-uniquing as the MDNode version used by other metadata node types. This also necessitated a change to the context destructor, since in some cases we end up with DIArgList as distinct nodes: DIArgList is the only metadata node type to have a custom dropAllReferences, so we need to invoke that version on DIArgList in the DistinctMDNodes store to clean it up properly. Differential Revision: https://reviews.llvm.org/D108968 (cherry picked from commit badcd58)
If the parameter had been annotated as nonnull because of the null check, we want to remove the attribute, since it may no longer apply and could result in miscompiles if left. Similarly, we also want to remove undef-implying attributes, since they may not apply anymore either. Fixes PR52110. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D111515 (cherry picked from commit 6404f4b)
When performing CFG based analyses, don't forget to check the child statements of an asm goto, such as the expressions used for inputs+outputs. Fixes: llvm/llvm-project#51024 Fixes: ClangBuiltLinux/linux#1439 Reviewed By: void, jyknight, jyu2, efriedma Differential Revision: https://reviews.llvm.org/D116059 (cherry picked from commit 3a604fd)
This change fixes a compiler crash that was introduced in https://reviews.llvm.org/D103611: `Sema::BuildVAArgExpr` attempted to retrieve a corresponding signed type for `bool` by calling `ASTContext::getCorrespondingSignedType`. rdar://86580370 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D116272 (cherry picked from commit c033f0d)
This environment variable has been standardized for reproducible builds. Setting it can help to have reproducible tests too, so keep it as part of the testing env when set. See https://reproducible-builds.org/docs/source-date-epoch/ Differential Revision: https://reviews.llvm.org/D108332 (cherry picked from commit 46c947a)
…lee pop. The interface for these instructions changed with support for mandatory tail calls, and now -1 indicates the CalleePopAmount argument is not valid. Unfortunately I didn't realise FastISel or GISel did calls at the time so didn't update them. (cherry picked from commit 0b5b35f)
llvm.is.constant* intrinsics are evaluated to 0 or 1 integral values.
A common use case for llvm.is.constant comes from the higher level
__builtin_constant_p. A common usage pattern of __builtin_constant_p in
the Linux kernel is:
void foo (int bar) {
if (__builtin_constant_p(bar)) {
// lots of code that will fold away to a constant.
} else {
// a little bit of code, usually a libcall.
}
}
A minor issue in InlineCost calculations is when `bar` is _not_ Constant
and still will not be after inlining, we don't discount the true branch
and the inline cost of `foo` ends up being the cost of both branches
together, rather than just the false branch.
This leads to code like the above where inlining will not help prove bar
Constant, but it still would be beneficial to inline foo, because the
"true" branch is irrelevant from a cost perspective.
For example, IPSCCP can sink a passed constant argument to foo:
const int x = 42;
void bar (void) { foo(x); }
This improves our inlining decisions, and fixes a few head scratching
cases were the disassembly shows a relatively small `foo` not inlined
into a lone caller.
We could further improve this modeling by tracking whether the argument
to llvm.is.constant* is a parameter of the function, and if inlining
would allow that parameter to become Constant. This idea is noted in a
FIXME comment.
Link: ClangBuiltLinux/linux#1302
Reviewed By: kazu
Differential Revision: https://reviews.llvm.org/D111272
(cherry picked from commit 9697f93)
This option is for groups who need time to accomodate the ld.lld -z start-stop-gc default. This is a modified version of https://reviews.llvm.org/D114186 that enables this option by default.
This fixes bug52896. Simply, some symmetric transfer optimization chances get invalided due to we delete some inlined optimization passes in 822b92a. This would cause stack-overflow in some situations which should be avoided by the design of coroutine. This patch tries to fix this by transforming the constant CmpInst instruction which was done in the deleted passes. Reviewed By: rjmccall, junparser Differential Revision: https://reviews.llvm.org/D116327 (cherry picked from commit 403772f)
(cherry picked from commit b4fb423)
This reverts commit 9d9efb1. This commit caused #53185.
… libunwind (cherry picked from commit 3db1ade)
Some of the Arm complex pattern functions call canExtractShiftFromMul, which can modify the DAG in-place. For this to be valid and handled successfully we need to define ComplexPatternFuncMutatesDAG. Differential Revision: https://reviews.llvm.org/D107476 (cherry picked from commit 77e8f4e)
Clang 13 has a -fsanitize-coverage -fno-semantic-interposition bug (D117190) which may lead to `relocation R_X86_64_PC32 cannot be used against symbol` linker error in -DLLVM_USE_SANITIZE_COVERAGE=ON build when a shared object is built (e.g. -DLLVM_BUILD_LLVM_DYLIB=on). For simplicity, just disallow Clang 13 entirely. Note: GCC -fPIC performance benefits from -fno-semantic-interposition dramatically. Clang benefits little. Using this option is more for a dogfood purpose to test correctness of this option, because in the wild some important packages like CPython uses this option. Differential Revision: https://reviews.llvm.org/D117183 (cherry picked from commit 1661c8c)
…(PR51974) This intention of this code turns out to be superfluous as we can handle this with shuffle combining, and it has a critical flaw in that it doesn't check for dependencies. Fixes PR51974 (cherry picked from commit 468ff70)
|
I'm not sure why GitHub complains that the branch cannot be rebased. It is already based on |
|
We probably need to push these commits to the target branch by hand. According to the following discussion, there is no workaround for this GitHub limitation: https://github.community/t/weird-problem-with-cannot-be-rebased-due-to-conflicts/178433 |
|
This is full of mainline LLVM project commits, what review policy shall we take on this? |
|
We will wave the review. @bryanpkc will merge this. |
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.
Update the branch with stability fixes from upstream.