[🍒 swift/release/6.1] Import missing release/19.x commits #9760
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
…leting (llvm#113443)" for non-Android Linux only (llvm#115790) The original patch (25fd366) was reverted in 083a5cd because it broke some buildbots. This revised patch makes two changes: - Reverts to *pre-llvm#98200* behavior for Android. This avoids a build breakage on Android. - Only define KeepUnblocked if SANITIZER_LINUX: this avoids a build breakage on solaris, which does not support internal_sigdelset. N.B. Other buildbot failures were non-sanitizer tests and are therefore unrelated. Original commit message: My earlier patch llvm#98200 caused a regression because it unconditionally unblocked synchronous signals, even if the user program had deliberately blocked them. This patch fixes the issue by checking the current signal mask, as suggested by Vitaly. It also adds tests. Fixes llvm#113385 (cherry picked from commit 531acf9)
So far we have assumed that we only rethrow the exception caught in the innermost EH pad. This is true in code we directly generate, but after inlining this may not be the case. For example, consider this code: ```ll ehcleanup: %0 = cleanuppad ... call @Destructor cleanupret from %0 unwind label %catch.dispatch ``` If `destructor` gets inlined into this function, the code can be like ```ll ehcleanup: %0 = cleanuppad ... invoke @throwing_func to label %unreachale unwind label %catch.dispatch.i catch.dispatch.i: catchswitch ... [ label %catch.start.i ] catch.start.i: %1 = catchpad ... invoke @some_function to label %invoke.cont.i unwind label %terminate.i invoke.cont.i: catchret from %1 to label %destructor.exit destructor.exit: cleanupret from %0 unwind label %catch.dispatch ``` We lower a `cleanupret` into `rethrow`, which assumes it rethrows the exception caught by the nearest dominating EH pad. But after the inlining, the nearest dominating EH pad is not `ehcleanup` but `catch.start.i`. The problem exists in the same manner in the new (exnref) EH, because it assumes the exception comes from the nearest EH pad and saves an exnref from that EH pad and rethrows it (using `throw_ref`). This problem can be fixed easily if `cleanupret` has the basic block where its matching `cleanuppad` is. The bitcode instruction `cleanupret` kind of has that info (it has a token from the `cleanuppad`), but that info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s `cleanupret` node does not have any arguments: https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/include/llvm/Target/TargetSelectionDAG.td#L700 Note that `catchret` already has two basic block arguments, even though neither of them means `catchpad`'s BB. This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node in ISel and uses it in the Wasm backend. Because this node is also used in X86 backend we need to note its argument there too but nothing more needs to change there as long as X86 doesn't need it. --- - Details about changes in the Wasm backend: After this PR, our pseudo `RETHROW` instruction takes a BB, which means the EH pad whose exception it needs to rethrow. There are currently two ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic and the other is from `CLEANUPRET` we discussed above. In case of `llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As written in the comments, this PR doesn't change how this BB is computed. The BB argument will be converted to an immediate argument as with other control flow instructions in CFGStackify. In case of `CLEANUPRET`, it already has a BB argument pointing to an EH pad, so it is just converted to a `RETHROW` with the same BB argument in LateEHPrepare. This will also be lowered to an immediate in CFGStackify with other control flow instructions. --- Fixes llvm#114600.
Promote v2i8 to v2i16, fixes a crash. Re-enable a test in NVPTX/vector-returns.ll Partial cherry-pick of fda2fea w/o the test which does not exist in release/19.x llvm#104864
…aries (llvm#116735) There are a couple changes in this PR that help getting clang-repl to run in the browser. Using a jupyterlite instance for the example pasted below 1) Updating flags responsible for generating shared wasm binaries that need to be dynamically loaded Most Importantly as can be seen in the changes `shared` and `allow-undefined` are crucial.  2) While exiting we encounter this.  Now as can be seen here https://github.com/llvm/llvm-project/blob/cd418030de7ae75750bc4e48d1238baf03c675e5/clang/lib/Interpreter/Interpreter.cpp#L421-L430 We call cleanUP in the destructor. Now cleanUP through IncrementalExecutor tries to deinitialize the JIT which wasn't even intialized as runCtors in wasm.cpp is a no-op https://github.com/llvm/llvm-project/blob/cd418030de7ae75750bc4e48d1238baf03c675e5/clang/lib/Interpreter/IncrementalExecutor.cpp#L94-L101 https://github.com/llvm/llvm-project/blob/cd418030de7ae75750bc4e48d1238baf03c675e5/clang/lib/Interpreter/Wasm.cpp#L107-L109 (cherry picked from commit 752dbd6)
This parameter seems unintentional here; we're trying to grep
the input on stdin, from the earlier stage in the pipeline.
Since a recent update on Github Actions runners, the previous
form (grepping a file, while piping in data on stdin) would fail
running the test, with the test runner Python script throwing
an exception when evaluating it:
File "D:\a\llvm-mingw\llvm-mingw\llvm-project\llvm\utils\lit\lit\TestRunner.py", line 935, in _executeShCmd
out = procs[i].stdout.read()
^^^^^^^^^^^^^^^^^^^^^^
File "C:\hostedtoolcache\windows\Python\3.12.7\x64\Lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: a bytes-like object is required, not 'NoneType'
(cherry picked from commit c2717a8)
Resolves a FIXME and avoids needing to workaround llvm#116075. Adding parentheses around the (vsplat_imm_eq_1) fixes the error cited in the FIXME by changing the ComplexPattern from a leaf node to an operator. (cherry picked from commit 2f4572f)
…hen there are predicate calls (llvm#116075) On loongarch64 with lsx extension, we select `VBITREV_W` for `v4i32 (xor X, (shl splat(1), Y))`: https://github.com/llvm/llvm-project/blob/8e6630391699116641cf390a10476295b7d4b95c/llvm/lib/Target/LoongArch/LoongArchLSXInstrInfo.td#L1583-L1584 And `vsplat_imm_eq_1` is defined as: https://github.com/llvm/llvm-project/blob/8e6630391699116641cf390a10476295b7d4b95c/llvm/lib/Target/LoongArch/LoongArchLSXInstrInfo.td#L77-L87 For the `(bitconvert (v4i32 (build_vector)))` case, the pattern is expected to be: ``` PATTERN: (xor:{ *:[v4i32] } v4i32:{ *:[v4i32] }:$vj, (shl:{ *:[v4i32] } (bitconvert:{ *:[v4i32] } (build_vector:{ *:[v4i32] }))<<P:Predicate_vsplat_imm_eq_1>>, v4i32:{ *:[v4i32] }:$vk)) RESULT: (VBITREV_W:{ *:[v4i32] } v4i32:{ *:[v4i32] }:$vj, v4i32:{ *:[v4i32] }:$vk) ``` However, `simplifyTree` drops the `bitconvert` node and its predicates: https://github.com/llvm/llvm-project/blob/8e6630391699116641cf390a10476295b7d4b95c/llvm/utils/TableGen/Common/CodeGenDAGPatterns.cpp#L3036-L3062 Then llvm will match `vsplat_imm_eq_1` for any v4i32 splats and cause a miscompilation: ``` PATTERN: (xor:{ *:[v4i32] } v4i32:{ *:[v4i32] }:$vj, (shl:{ *:[v4i32] } (build_vector:{ *:[v4i32] }), v4i32:{ *:[v4i32] }:$vk)) RESULT: (VBITREV_W:{ *:[v4i32] } v4i32:{ *:[v4i32] }:$vj, v4i32:{ *:[v4i32] }:$vk) ``` This patch adds additional checks for predicates associated with the trivial bitconvert node. Unused patterns in the LoongArch target are also removed. Fixes llvm#116008. (cherry picked from commit c727b48)
…lvm#116794) Closes llvm#116775. (cherry picked from commit 03d8831)
Range checks for R_HEX_B22_PCREL did not account for the fact that offset is measured in instructions, not bytes. Add a test for all range-checked relocations.
Fixes llvm#116809. After running some passes (SimpleLoopUnswitch, LoopInstSimplify, etc.), MemorySSA might be outdated, and the instruction `I` may have become a non-memory touching instruction. LICM has already handled this, but it does not pass `CreationMustSucceed=false` to `createDefinedAccess`. (cherry picked from commit 18b02bb)
… code model This commit fixes an issue in the large code model where non-dso_local function calls did not use the GOT as expected in PIC mode. Instead, direct PC-relative access was incorrectly applied, leading to linker errors when building shared libraries. For `ExternalSymbol`, it is not possible to determine whether it is dso_local during pseudo-instruction expansion. We use target flags to differentiate whether GOT should be used. Cherry-picked from llvm#117099, used for fix linker errors when bulding shared libraries with large code model.
Counterexample: 219 is a multiple of 73. But `sext i8 219 to i16 = 65499` is not. Fixes llvm#116483. (cherry picked from commit 458dfbd)
…conditions (llvm#116627) This patch bails out non-dedicated exits to avoid adding exiting conditions to invalid context. Closes llvm#116553. (cherry picked from commit 52361d0)
(cherry picked from commit a9b3ec1)
llvm#116987) The improvements in 63917e1 / llvm#70796 do not check for memory barriers/unmodelled sideeffects, which means we may incorrectly hoist loads across memory barriers. Fix this by checking any machine instruction in the loop is a load-fold barrier. PR: llvm#116987 (cherry picked from commit ef102b4)
Closes llvm#112068. (cherry picked from commit a59976b)
(cherry picked from commit 825f9cb)
…t of minbitwidth transformation Need to check that the operand of the abs intrinsic can be safely truncated before making it part of the minbitwidth transformation. Fixes llvm#112577 (cherry picked from commit 709abac)
The default value of this CPU affects the `FeatureBits` obtained by `LoongArchTargetELFStreamer` when creating an ELF file, and it will further affect the `Flags` field in the generated file. So, the default CPU value should be consistent with the `initializeSubtargetDependencies` in `LoongArchSubtarget.cpp`. Otherwise, the `Flags` field may be unexpected. (cherry picked from commit 75c2888)
The bug was introduced by llvm#68473 Fixes: llvm#102351 (cherry picked from commit 3c9022c)
Remove check for PHI in pred as pointed out in llvm#103688 Reduced the testcase to remove redundant phi in pred Fixes: llvm#102351 (cherry picked from commit 39601a6)
… in browser (llvm#117978) Co-authored-by: Vassil Vassilev <[email protected]> (cherry picked from commit a174aa1)
On Darwin we don't have any hardware that has SVE support, only SME. Therefore we don't need to save VG for unwinders and can safely omit it. This also fixes crashes introduced since this feature landed since Darwin's compact unwind code can't handle the presence of VG anyway. rdar://131072344
… required. (llvm#104588) The compact unwind format requires all registers are stored in pairs, so return false from produceCompactUnwindFrame if we require saving VG.
…m#110855) The iterator passed to `fixupCalleeSaveRestoreStackOffset` may be incorrect when it tries to skip over the instructions that get the current value of 'vg', when there is a 'rdsvl' instruction straight after the prologue. That's because it doesn't check that the instruction is still a 'frame-setup' instruction.
If we create a cross toolchain with a ${triple}-ld.lld symlink, clang
finds that symlink and when it uses it, it's not recognized as "lld".
Let's resolve that symlink and consider it when determining lld-ness.
For example, clang provides hexagon-link specific link arguments such as
`-mcpu=hexagonv65` and `-march=hexagon` when
hexagon-unknown-linux-musl-ld.lld is found. lld rejects this with the
following error:
hexagon-unknown-linux-musl-ld.lld: error: unknown emulation:
cpu=hexagonv65
(cherry picked from commit 2dc0de7)
…lvm#107780) In the case of `--wasm64` we were setting the type of the init expression to be 64-bit but were only setting the low 32-bits of the value (by assigning to Int32). Fixes: emscripten-core/emscripten#22538 (cherry picked from commit 5c8fd1e)
Error: CommandLine Error: Option 'attributor-manifest-internal' registered more than once During the standalone debug build of offload the above error is seen at app runtime when using a prebuilt llvm with LLVM_LINK_LLVM_DYLIB=ON. This is caused by linking both libLLVM.so and various archives that are found via llvm_map_components_to_libnames for jit support.
Include CheckCXXCompilerFlag before it is used in the top-level CMake file. This fixes standalone builds, but it is also cleaner than assuming that some previous CMake file will include it for us.
Add the `omp` target dependency to tests only when the respective target is present, i.e. when not building standalone against system libomp.
Copy the `OPENMP_TEST_FLAGS` and `OPENMP_TEST_OPENMP_FLAGS` from openmp for standalone builds, as required by the lit configs.
Define `LIBOMPTARGET_OPENMP_HEADER_FOLDER` and `LIBOMPTARGET_OPENMP_HOST_RTL_FOLDER` needed for testing in standalone builds.
Fix the DetectTestCompiler project use to reference the openmp source tree, since the respective files were not copied to offload, and there is no point in duplicating them. Fixes llvm#90333
…asm objects (llvm#111008) (cherry picked from commit ac5dd45)
Follow on from llvm#111008. (cherry picked from commit ed91843)
…oads A miscompilation issue has been addressed with improved handling. Fixes: llvm#118467. (cherry picked from commit f68b0e3)
Fixes llvm#117537. (cherry picked from commit fc5c899)
LLVM is not evaluating X u > C, a, b the same way it evaluates X <= C, b, a. To fix this, let's move the folds to after the canonicalization of -1 to TrueVal. Let's allow splat vectors with poison elements to be recognized too! Finally, for completion, handle the one case that isn't caught by the above checks because it is canonicalized to eq: X == -1 ? -1 : X + 1 -> uadd.sat(X, 1) Alive2 Proof: https://alive2.llvm.org/ce/z/WEcgYH
|
Thankfully most commits are signed by @tru's PGP key so there is cryptographic proof these commits were merely imported without any modification. |
|
I just realized 2 stray commits ended up in this branch from a different cherry-pick PR of mine. Will remove and force-push. |
AZero13
changed the title
|
Or maybe the stable branch should be the base instead? |
|
Nvm there may be a 19.1.7 but only because of emergency patches for a typo in the RISCV backend and like 2 other link-time bugfixes. |
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.
It would be nice if the automerge bot did not stop picking from 19.x once we branched, but alas. Now that 19.x is forever finished, now would be a good time to have every commit in that branch since we merged. Thankfully, it's 40ish commits we can verify all came from the 19.x release branch, so the end result should be the same and verifiable.
Though I agree it is not ideal to have a PR with 40 commits. Is there an easier way to do that? Asking for a friend.