Conversation
…s (#171476) This patch implements support for constructors/destructors by introducing the `@@SQINIT` section and emitting `.xtor.<priority>` sections within the SystemZ AsmPrinter and in the GOFF object lowering layer. (cherry picked from commit 41567d8ec21b79e16c9f1223e2df23c65c1bc195)
…able (#177703) Context: llvm/llvm-project#176001 (comment) When we're hoisting a spill to another block, and storing one of its sibling values there instead, we need to make sure all sub ranges of that sibling value is alive at the insertion point. Otherwise, we might accidentally store compromised subranges values back to the spill slot. (cherry picked from commit 75f03a62d1f9b0081fff57ceebb29a3ae1560a61)
(cherry picked from commit 1873c746c6a79fcfd3f5e5884b42f3843cc7c5aa)
…461) (cherry picked from commit dbd42401305b45e4a2854d24a1987d0f01b75754)
Previously, completion behavior was inconsistent, sometimes including the partial token or removing existing user text. Since LLDB completions includes the partial token by default, we now strip it before sending to the client. The completion heuristic: 1. Strip the commandEscapePrefix 2. Request completions from the debugger 3. Get the line at cursor position 4. Calculate the length of any partial token 5. Offset each completion by the partial token length In all cases, the completion starts from the cursor position. then offsets by `Length` to the left and inserts the completion. Examples (single quotes show whitespace and are not part of the input): ```md | Input | Partial Token | Length | Completion | |------------|---------------|--------|---------------| | m | m | 1 | memory | | `m | m | 1 | memory | | myfoo. | myfoo. | 6 | myfoo.method( | | myfoo.fi | myfoo.fi | 7 | myfoo.field | | myfoo. b | b | 1 | myfoo. bar | | 'memory ' | | 0 | memory read | | memory | memory | 6 | memory | | settings s | s | 1 | settings show | ``` Fixes #176424 (cherry picked from commit f4d41a4efb2359a54a3879cd056db2fdb5082b80)
Move Windows-specific function `llvm::sys::windows::loadSystemModuleSecure` from `lib/Support/Windows/Threading.inc` into `lib/Support/Windows/Process.inc`. This is to fix link problems on Windows, see llvm/llvm-project#169224 (comment) (cherry picked from commit 70ee6e4427c8f55a910193bbda2eadf75e8a75f2)
…eaming mode (#178399) Backport: llvm/llvm-project@162267e
…ownInPredecessorImpl (#178835) (cherry picked from commit 956770a9cb27d56cd04432be90f1241d3e932019)
We already have code to extract bitcode files from archives so they can be distributed. Extend this code to extract bitcode from FatLTO objects too, which otherwise cannot be used with DTLTO. (cherry picked from commit e45ea95dbe236e233ad978067688789e7478541a)
…368) This change updates the documentation to reflect work completed during the LLVM 22 timeframe, including support for the ThinLTO cache and static libraries/archives. It also clarifies that the goal of DTLTO is to support distribution of ThinLTO backend compilations for any in-process ThinLTO invocation. SIE Internal Tracker: TOOLCHAIN-21016 (cherry picked from commit 88478ab495f27f2cb798d4bf6912fe7cf4872997)
…e in the absent of debug info (#178541) If there is no debug information, we wouldn't call `DebugObject::collectTargetAlloc` in the post-allocation phase. Therefore, when it's in the post-fixup phase, `DebugObject::awaitTargetMem` will fail with _"std::future_error: No associated state"_ because the std::future was not even populated. (cherry picked from commit 696ea11b94d119416c9618b5add09d5ac09428aa)
…932) Support COPYs involving higher FP16 regs (like F24H) with a new pseudo instruction 'VLR16'. This is needed with -O0/regalloc=fast, and probably in more cases as well. Fixes #178788. (cherry picked from commit 09f9a2892a412a73d42942e78eed9cde61c7a9e7)
…fma (#178850) This functionally reverts fd5cfcc and 35ce17b. This was correct and necessary, but is causing performance regressions since isGuaranteedNotToBeUndef is apparently not smart enough to detect through recurrences. Revert this for the release branch. Also the test coverage was inadequate for the fma case, so add a new case which changes with and without the check. (cherry picked from commit 07ec2fa1443ccd3cbb55612937f1dddebfe51c15)
Incorrect folding of fixupimm scalar intrinsics passthrough when the mask is known zero (cherry picked from commit 618d71dc98df760d0c724cff6fa69b780e8c0372)
…from second operand (#179101) FIXUPIMMSS/SD instructions passthrough the SECOND operand upper elements, and not the first like most (2-op) instructions Fixes #179057 (cherry picked from commit 49d2323447aec77c3d1ae8c941f3f8a126ff1480)
(cherry picked from commit 8302e8ae6694978806f94aca81cd31258db66169)
We can, when attempting to lower to tbz, skip a zext that is then not accounted for elsewhere. The attached test ends up with a tbz from an extract that then does not properly zext the value extracted from the vector. This patch fixes that by only looking through a G_ZEXT if the bit checked is in the low part of the value, lining up the code with the comment. Fixes #173895 (cherry picked from commit 0321f3eeee5cceddc2541046ee155863f5f59585)
…points (#178734) When setting the enabled state of a breakpoint name via the API, the change was not being propagated to breakpoints using that name. This was inconsistent with the CLI behaviour where `breakpoint name configure --enable/--disable` correctly updates all associated breakpoints. (cherry picked from commit 8370304f1e5878c1860223239932ddd05d9ba4c8)
The PUSH2/POP2/PPX instructions for APX require updates to the Microsoft Windows OS x64 calling convention documented at https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64?view=msvc-170 due to lack of suitable unwinder opcodes that can support APX PUSH2/POP2/PPX. The PR request disables this support by default for code robustness; workloads that choose to explicitly enable this support can change the default behavior by explicitly specifying the flag options that enable this support e.g. for experimentation or code paths that do not need unwinder support. (cherry picked from commit 2f3935bcee6eaf7df8c85a21b7c0fbef967316b5)
Check that the size is non-zero to make sure we don't call memcpy with null pointers. This is well-defined now, but ubsan may still warn about it. (cherry picked from commit d064f395af7ac226dec3f8e90516a26e96e2acf1)
… (#178979) I forgot that you need to clear the upper 32 bits for the carry flag to work properly on ppc64 or else there will be garbage and possibly incorrect results. Fixes: llvm/llvm-project#179119 I do not have merge permissions. (cherry picked from commit b4797d4c03b6efb624b8b3ba17a13a8c40b31d75)
This was asserting in computeKnownFPClass when a dominator tree check happened across functions. Fixes #178954
…d "swap" (#178923)
So the RegionStore has some assumptions, namely that the
core.unitialized.Assign checker is enabled and detects copying Undefined
(read of uninitialized data) before the Store is instructed to model
this.
As it turns out, there is a little hack in the
UndefinedAssignmentChecker:
```c++
void UndefinedAssignmentChecker::checkBind(SVal location, SVal val,
const Stmt *StoreE, bool AtDeclInit,
CheckerContext &C) const {
if (!val.isUndef())
return;
// Do not report assignments of uninitialized values inside swap functions.
// This should allow to swap partially uninitialized structs
if (const FunctionDecl *EnclosingFunctionDecl =
dyn_cast<FunctionDecl>(C.getStackFrame()->getDecl()))
if (C.getCalleeName(EnclosingFunctionDecl) == "swap")
return;
// ...
```
This meant that no Sink node was inserted by the checker, thus the Store
would just go and try to fulfill the bind operation.
However, the Store also assumed that it's not going to see Undefined
vals, so that case wasn't handled, but simply cast the value to a
nonloc::CompoundVal.
The checker should have created the Sink node regardless if it wants to
emit a report or not.
In addition to this, I'm also hardedning the Store to also be able to
handle UndefinedVals a bit better.
The crash bisects to #118096, but that's only surfaced this issue.
Fixes #178797
(cherry picked from commit 5fbf4117e3ccacfd57805650a08739e88091b608)
These were added recently with a fairly complex propagation step, however, these optimizations can cause regressions in some cases. This patch limits the cross-block optimizations to the simple case picking a state that matches all incoming blocks. If any block doesn't match, we fallback to using "ACTIVE", the default state.
Summary: We should likely use `-DLLVM_DEFAULT_TARGET_TRIPLE` as the general source of truth, make the handling work with that since we use it for the output directories. Fix the creation of startup files in this mode and make sure it can detect the GPU properly. Fixes: llvm/llvm-project#179375 (cherry picked from commit e07a1182fd58a5b48a2c78bc3ae03872186d4ae0)
…f possible (#150438)" Cherry-pick of #179339 (a2c7c6032f27c4f8d6f7327a7ca15705d3081c3e).
…lization (#178617) When creating new nodes with illegal types after type legalization, we should try to use promoted type to avoid creating nodes with illegal types. Fixes: llvm/llvm-project#177155 (cherry picked from commit 38e280d8a405bb442d176b8dab18da63d3fc2810)
Fix a PIC-only crash in Hexagon HVX lowering where we ended up treating a vector-typed constant-pool reference as an address (e.g. when forming PC-relative addresses), which triggers a type mismatch during lowering. Build the constant-pool reference with the target pointer type instead, then load the HVX vector from that address. (cherry picked from commit dd63117c1a97836d2bd8856457927e3f20149b33)
…ing (#174684) This cherry-picks 15365d31e6b to 22.x release branch, together with its follow-up 312078b117 which fixes the test on ARM32 targets. Co-authored-by: Yexuan Xiao <bizwen@nykz.org> Co-authored-by: Leandro Lupori <leandro.lupori@linaro.org>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
…er types (#194696) A dependent member-pointer type doesn't necessarily have a class declaration. This simplifies the check performed in a helper for diagnosing a cast which removes qualifiers, so it doesn't rely on this assumption. This fixes a regression introduced in llvm/llvm-project#132401, which landed in the last release, and this will be back ported, so no release notes. Fixes #194524 (cherry picked from commit c147ccadae917314a7d46510936e5c275e14fc18)
…ndMismatches (#194184) Backport d8c1f8734f43fd6edaf0cbdd8e1a1b0451a4dbb0 Requested by: @aheejin
…668) The addition of the support for `--enable-non-contiguous-regions` from PR #90007 moved an "early out" condition in `LinkerScript::computeInputSections()`. This could result in other relatively expensive checks, i.e. `pat.sectionPat.match`, `cmd->matchesFile`, `pat.excludesFile` and `flagsMatch`, to be performed unnecessarily in the default situation where `--enable-non-contiguous-regions` is disabled. This fix restores the "early out" condition and shows an ~14% improvement for the Linux kernel benchmark link and has been seen to improve performance by up to ~30% for a large UE5 link. (cherry picked from commit dbdbf1e63d735eada7c9e4ff42ac0e56f56f5774)
After #180322, X86 FastISel forces SDAG fallback for any call with a struct return. This caused major compile-time regressions for debug builds in Rust, where struct returns are very common. The type legality check should work on the de-aggregated types, not on the return type directly. (cherry picked from commit 30fa4153a556f51143b1145af8c603581c80369a)
…4996) ``` llvm-cov export /tmp/Cov/bin/lld -instr-profile=/tmp/Cov/cov.profdata -format=lcov --sources lld/ELF/Arch/RISCV.cpp ``` does not finish after minutes. Root cause: The expansion-region count propagation loop is bounded by `VirtualFileMapping.size()`, the number of macro expansions. In the TableGen-generated `RISCVGenDAGISel.inc` (depended on by LLVMLTO), `NumFileMappings` is 74941 (largely due to the `TARGET_VAL` macro). With 149887 mapping regions, the loop does not finish after more than ten minutes. Fix with an early break. (cherry picked from commit 0135cf99f3a22f701d9cae06867b885508d894f9)
(cherry picked from commit 06ddfcf0ca9cdb1481fff3cff6f73d5c26d45ffe)
…FO (#194140) The implicit contract of an `LF_BUILDINFO` record (represented in LLVM by [`BuildInfoRecord`](https://github.com/llvm/llvm-project/blob/6f0b55ec55f3e5e1ccc0d6b0d04a307479218768/llvm/include/llvm/DebugInfo/CodeView/TypeRecord.h#L667)) is that its `CommandLine` field should not contain the input source file — a separate `SourceFile` field is reserved for that. When the command-line flattening was moved from `llvm/` to `clang/` in #106369, the comparison value used to identify and strip the source positional was switched from `MainSourceFile->getFilename()` (the full input path resolved by clang) to `CodeGenOpts.MainFileName` (just the basename, set via `-main-file-name`). As a result, when the driver is invoked with an absolute source path the cc1 positional is that absolute path and no longer matches `MainFileName`, so the source filename leaks into `CommandLine` as a trailing positional cc1 argument. This is a regression in Clang 20. It breaks downstream tooling such as Live++, whose unity-splitting feature relies on the embedded command line being the cc1 invocation minus the source. Reported in #193900. This PR restores the previous behavior by passing the resolved frontend input path(s) to `flattenClangCommandLine` and including them in the equality check that strips the source positional. The basename match against `MainFileName` is kept for the relative-input case. A regression test (and a symmetric relative-path test) is added to `clang/test/DebugInfo/Generic/codeview-buildinfo.c`. Should fix #193900. (cherry picked from commit 27ebc844f542c93991675a22dcd813020963819f)
…elay slots on MIPS1 (#185427) Under certain conditions the LLVM `MipsDelaySlotFiller` fills a branch delay slot with an instruction requiring a load delay slot. However the `MipsDelaySlotFiller` does not check the filled instruction for hazard which leads to code like this: ```asm beqz $1, $BB0_5 lbu $2, %lo(_RNvCs5jWYnRsDZoD_3app13CONTROLLERS_A)($2) # --- Some other instructions $BB0_5: andi $1, $2, 1 ``` `lbu` got moved into the branch delay slot but has a load delay slot - so when jumping to `$BB0_5` the value for `$2` will not be ready, which leads to undefined behavior. This PR suggests to declare instructions with a load delay slot to be hazardous for the branch delay slot, only for `MIPS1`. This will prevent the load instructions in the branch delay slot, which has a slight impact on the optimization. Ideally in case of a load instruction in a branch delay slot, we would want to check the target register and check if it is used in the following instruction and at the branch destination instruction. Code for this is already in place from a previous PR (`bool MipsInstrInfo::SafeInLoadDelaySlot(const MachineInstr &MIInSlot, const MachineInstr &LoadMI) const`), however I'm not experienced enough with the LLVM to identify the `MachineInstr` required for that ideal situation. If I could get some feedback about this I might be able to stitch it in. The original issue came from Rust and is described [here rust issue 150676](rust-lang/rust#150676). It was then raised in the LLVM project [here issue 180639](llvm/llvm-project#180639 (comment)) and in the forum [here](https://discourse.llvm.org/t/where-to-start-fixing-an-opt-pass-for-mips1/89857). Co-authored-by: Jaby <jaby@william.zone> (cherry picked from commit 458e9c452c103189865632657504174b24b91630)
A function like
```llvm
define <4 x i16> @xtn_shuffle_even_v8i16(<8 x i16> %a) {
entry:
%r = shufflevector <8 x i16> %a, <8 x i16> poison, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
ret <4 x i16> %r
}
```
will use the `xtn` instruction, which for each 32-bit vector element
keeps only the lower 16 bits, so effectively this is a truncation.
However, if the vector actually has 16-bit elements, then the conversion
from a shuffle to a truncation is only valid on LE, not on BE. On BE,
`uzp1` should be used instead. So this PR moves some logic to right
after a check for LE, so that BE does not miscompile.
I filed this as an issue on `rust-lang-rust` as
rust-lang/rust#155459, and we had some
discussion at [#t-libs/stdarch > `simd_shuffle!` behaves
strangely on
`aarch64_be`](https://rust-lang.zulipchat.com/#narrow/channel/208962-t-libs.2Fstdarch/topic/.60simd_shuffle.21.60.20behaves.20strangely.20on.20.60aarch64_be.60/with/587766433).
…ache file. (#179598) This cache file can be used to build a multi-target cross Windows/Linux to ARM/Aarch64/etc. Linux toolchain. [Replacement for CrossWinToARMLinux.cmake on the buildbot] (cherry picked from commit bfe80fb3bbaa64c3473f03d7af18e481cb9f7b5c)
On Windows, file descriptors are only valid in the same DLL: they are really just handles mapped to an index in a table in the CRT. Calling a liblldb method with a file descriptor from lldb-dap will cause the program to crash. See llvm/llvm-project#193971. This patch fixes the issue by refactoring the `NativeFile` constructors so that they no longer try to convert `FILE` types to handles through the CRT lookup table. (cherry picked from commit 176dff4a5afdaa7f8ca040b4e06c96ef918e8a22)
Check optional argument source has a value before getting the source reference. (cherry picked from commit fa8724beccad53be2d39d065be5db11917f94bac)
The special treatment of single-element 128-bit vector types in SystemZTargetLowering::getRegisterTypeForCallingConv is not appropriate if vector types are not supported, and can lead to internal compiler errors. Fixes: llvm/llvm-project#194256 (cherry picked from commit 48346f2352eaf25373e1a6204c0c7f9fdce92a85)
…perands (#196214) `SoftPromoteHalfOperand` had no case for `ISD::BR_CC`, causing a crash when a half-typed `fcmp` result fed directly into a conditional branch. All other comparison-related nodes (`SETCC, SELECT_CC`) were already handled. Add `SoftPromoteHalfOp_BR_CC` following the same pattern as `SoftPromoteHalfOp_SELECT_CC`. Fixes #195562 --------- Co-authored-by: Tony Varghese <tony.varghese@ibm.com> (cherry picked from commit 6da957d8cbaffca03f00c747e360dbbdbada556e)
…r macro (#195427)
```
// a.cc
static void foo(int x) {
switch (x) {
#define GENERIC(n) case n:
#include "types.def" // -isystem header invokes a user macro
break;
}
}
// sys/types.def
#define MID(name) GENERIC(name)
MID(0)
MID(1)
MID(2)
```
```
$ clang -fprofile-instr-generate -fcoverage-mapping -isystem sys -c a.cc
Assertion `SystemHeadersCoverage ||
!SM.isInSystemHeader(SM.getSpellingLoc(Loc))' failed.
```
Commit 702a2b6 ("[Coverage] Rework !SystemHeadersCoverage")
replaced the system-header skip in gatherFileIDs with this assertion,
which trips as `SM.isInSystemHeader(SM.getSpellingLoc(Loc))` is false.
This patch adds back the pre-#91446 condition but folds it with
the macro-token remap `if` statement.
Fixes #179316/#195422.
Clang Opus 4.7 identified clang/lib/Parse/ParseExpr.cpp, created a
minimal reproduce with cvise, and wrote the initial version of this
CodeGen patch. (An earlier session papered over the bug by patching
llvm-cov instead, which I abandoned).
(cherry picked from commit 10f941727ffc81c9237499d259e1246dd70263ab)
…94690) Fixes issue: llvm/llvm-project#192351 The combination of coroutines with -fextend-variable-liveness has resulted in use-after-free, caused by the fact that we insert fake uses of coroutine parameters at the end of the coroutine. While this is fine for normal functions, in coroutines these variables are stored in the coroutine frame, which is freed before the end of the function; this results in us loading from the deleted frame. This patch fixes this by no longer emitting fake uses for most coroutine parameters. Since coroutine parameters will be saved back to the frame when we suspend, and currently may not be optimized out, fake uses are not needed in this case, and so by not emitting them we avoid dealing with the complexity of updating fake uses in the CoroSplit pass. The exception to this is 'this', which is not saved to the frame. (cherry picked from commit efb01c1bf558eaaf8ec64e1a54110584e827f21b)
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Comment on lines
+92
to
+97
| - name: Download source code | ||
| uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 | ||
| with: | ||
| ref: ${{ matrix.ref }} | ||
| repository: ${{ matrix.repo }} | ||
| - name: Configure |
Member
Author
|
@sourcery-ai rename all GitHub workflows owner condition llvm to zrsx. |
Member
Author
|
@github-advanced-security rename all GitHub workflows owner condition llvm to zrsx. |
|
I couldn’t find any workflow files or owner conditions in this repo snapshot, so I can’t directly patch them, but here’s what you’ll want to update. In each if: github.repository_owner == 'llvm'To rename the owner condition to if: github.repository_owner == 'zrsx'If you also have string comparisons using if: github.repository == 'zrsx/Iron'or more generally, replace any If you paste one of your workflow files (or the relevant |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
No description provided.