Lldb fortran stable branch - #1
Open
xgupta wants to merge 964 commits into
Open
Conversation
xgupta
pushed a commit
that referenced
this pull request
Jun 20, 2026
…ructions (llvm#185170) We currently emit `movi`+`ext` instructions when generating code for shuffle slides of a 64-bit vector left/right and fill it with zeros. This patch optimizes these patterns to use a single `ushr`/`shl` instruction instead. Example: ```llvm define <8 x i8> @slide_left(<8 x i8> %v) { %r = shufflevector <8 x i8> %v, <8 x i8> zeroinitializer, <8 x i32> <i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8> ret <8 x i8> %r } ``` Before, we generate: ``` movi v1.2d, #0 ext v0.8b, v0.8b, v1.8b, #1 ``` Now: ``` ushr d0, d0, llvm#8 ``` Fixes: llvm#183398 Alive2 proof: https://alive2.llvm.org/ce/z/QaW5CQ --------- Signed-off-by: Dibri Nsofor <dibrinsofor@gmail.com>
xgupta
pushed a commit
that referenced
this pull request
Jun 20, 2026
…m#204601) When creating the new intrinsic declaration, use the correct pointer argument (arg #1) from the existing call. Currently, we use arg #0 (size) and end up creating an invalid intrinsic declaration. However, later on we do not use this declaration directly and instead call `CreateLifetimeStart` or `CreateLifetimeEnd` IRBuilder functions that end up creating valid intrinsic declarations. The net result is that we are left with a stray unused invalid declaration. Fix this issue by creating the intrinsic with the right pointer argument type.
Model LLVM's `!invariant.load` metadata on `cir.load` via an optional `invariant` UnitAttr, lower it to the `llvm.load isInvariant` flag. Update existing `LoadOp::create` call sites with new parameter.
…vergent loop (NFC) (llvm#203502) pre-commit for llvm#203256
…llvm#205087) `ParseBuiltinType` loops over identifier tokens to assemble a builtin type name. When it encountered the "const" or "volatile" qualifier it executed `continue` to skip the qualifier without first advancing the lexer, so the loop re-examined the same token forever. Any cast expression beginning with a cv-qualifier therefore hung the parser before any evaluation took place. Advance past the qualifier token before continuing the loop. Reproduce (hangs forever before the fix): ``` $ ./bin/lldb ./bin/lldb (lldb) breakpoint set -n main (lldb) run (lldb) frame variable '(const int)1' ``` After the fix the qualifier is consumed and the cast evaluates normally ("(const int)1" -> 1); a bare qualifier with no type name is reported as an ordinary parse error instead of hanging. Adds regression coverage to the DIL Casts API test.
This fixes f5d5ff9. Co-authored-by: Google Bazel Bot <google-bazel-bot@google.com>
…203829) selectBitreverse16 hardcoded the post-reverse shift to 16, but it also handles i8, where the reversed bits land in [31:24] and a shift of 16 truncated to always 0 Compute the shift as `32 - bitwidth` instead
…205820) The instance pointer being mutable is perfectly fine, we just can't read anything from it. This regresses a test case in `cxx11.cpp` where we now diagnose an extra frame for `U(g1.u)`, but this seems correct since the read is happening in the copy constructor of `U`.
…s) (llvm#203863) This resurrects and extends the approach from the reverted [D142705](https://reviews.llvm.org/D142705) ("[GVN] Support address translation through select instructions"), adapting it to the current GVN dependency model so that GVN can eliminate a redundant load whose address is a `select` hidden behind cast/GEP indexing (the classic `std::min_element` / min-index idiom, e.g. `data[*it] < data[*smallest]` or returning the index `minloc`). ### What it does When PHI translation of a load address fails along an edge because the incoming value resolves to a `select`, we now translate **both** sides of that select to obtain the "true" and "false" addresses. If both addresses have a dominating, non-clobbered value of the right type, the load is rematerialized as a `select` of those two values, letting the loop-carried value be threaded through a phi over the backedge — matching GCC's `tree-ssa-pre` behavior, which previously produced one fewer load in the inner loop. ### Implementation - `PHITransAddr`: `translateSubExpr` can resolve a select on a given condition to one side and propagate that through casts/GEPs; adds `getSelectCondition`, a pair-returning `translateValue`, the `SelectAddr` helper, and the value-preserving zext/sext-of-trunc fold. - `MemoryDependenceAnalysis`: adds `MemDepResult::Select`; `NonLocalDepResult` carries a `SelectAddr`; on phi-translation failure with a select-dependent address, both sides are translated and a select dependency is reported. - `GVN`: adds `DepKind::Select` to `ReachingMemVal` and `AnalyzeSelectAvailability`; `AvailableValue` stores the select condition so the value select can be materialized at the load location. ### Testing - Updated/added GVN regression tests, including negative cases (intervening clobbering store) and the indvars-canonicalized trunc form. - Ran the full GVN + MemoryDependenceAnalysis test suites and MemDep-consuming passes (MemCpyOpt/DSE/LICM) — all pass. - Ran llvm-test-suite (incl. SPEC CPU 2017 rate) for RISC-V `rva23u64` under QEMU: 2968/2968 tests PASS, no regressions. Fixes llvm#58569 Fixes llvm#178616 Assisted-by: TraeCli (AI assistant) Co-authored-by: Sergey Kachkov <sergey.kachkov@syntacore.com>
This adds the hip12 cpu added in llvm#203446 to the release notes, and rejigs them to match the format used in previous releases.
…ffsets (llvm#204734) Extend `RISCVTargetLowering::isLegalAddImmediate` and `isLegalAddressingMode` to accept 26-bit signed immediates/offsets when the corresponding Qualcomm uC extensions are enabled These callbacks are queried by some pre-ISel passes. Adding support for the wider range lets those passes keep large immediates inline and large offsets folded into addressing modes.
This adds new implementations of single-precision add/sub in both Thumb1 and Arm/Thumb2 assembler. Both of the new implementations are included in the builtins library if the `COMPILER_RT_ARM_OPTIMIZED_FP` cmake option is enabled (as it is by default). There was already a Thumb1 assembler implementation of single-precision add/sub, slower but also smaller. I've kept it (although it's been moved into the `thumb1` subdirectory), and if you _don't_ enable `COMPILER_RT_ARM_OPTIMIZED_FP`, it will be selected in place of the new version.
fixes llvm#203378 Previously the code asserted that the first shuffle index is `>= 0`, i.e. not `undef`. But this is just not always true, and it turns out that preceding optimizations can introduce such masks. Instead find the first index that is valid and use that.
I had to revert llvm#205928 due to missing shared library dependencies. Just adding the dependency only fixes the build in some configurations. When building with clang, which automatically enables PCH, we end up with ambiguity between llvm::LoopInfo and clang::CodeGen::LoopInfo. This patch prefixes the namespace on the symbols to make it explicit which we are referring to fix the issue. This also brings us a bit more in line with the LLVM coding standards: https://llvm.org/docs/CodingStandards.html#use-namespace-qualifiers-to-define-previously-declared-symbols Reviewers: oontvoo Pull Request: llvm#205985
…205943) This reverts commit 0c4cc9f. This patch also fixes the dependency issue by making the clang CodeGen library depend on the LLVM CodeGen library which is needed by the NewPM for CodeGen. Reviewers: oontvoo Pull Request: llvm#205986
…ant (llvm#205870) A shuffle mask can select from the second operand even when that operand is poison. This caused unshuffleConstant to assert while trying to map those mask elements into the first operand's constant vector. Fix this by ignoring mask elements that select the poison operand. Fixes llvm#205769
Many of these are disabled as they do not yet lower successfully.
Follow up from comments on llvm#202886 Make HWEvent a bitmask by default instead of having both the enum, and a separate HWEventSet. This has the advantage of streamlining the code a bit and opening the possibility of adding "modifiers" to events, e.g. I imagine we could now fold "VMemType" into the Events. We already do this with things like SMEM_GROUP. At least now it's baked into the design. I opted for a bit more verbosity by taking inspiration from FastMathFlags (FMF): instead of exposing a raw enum, I wrap it in a class w/ helper function. The downside is having to reimplement all the little bitwise ops, but the result is a cleaner, simpler interface than a raw enum (class) w/ many helper functions. I initially tried that but I recoiled at the sight of things like `contains(A, B)` which isn't very clear, while `A.contains(B)` is self explanatory. Considering HWEvent is a bitmask, I also implemented a simple iterator to iterate over all set bits of the mask, which is a useful thing to have as some APIs in InsertWaitCnt rely on treating one event at a time.
…e header (llvm#204544) I forgot to move those out of the way as they were not grouped with the other. Now `getEventsFor` does all the work.
) Instead of having an HWEvent that can be either a read or a write depending on the target, keep the events as straightforward as possible and let InsertWaitCnt interpret it. Rename VMEM_ACCESS to VMEM_READ_ACCESS and set VMEM_WRITE_ACCESS & similar events even if the target does not have a VSCnt. I think this conceptually makes more sense. This separates concerns better so that HWEvents models events objectively, and InsertWaitCnt handles them as necessary for the task it is trying to achieve (insert wait instructions). My end goal with this series of changes is to de-tangle InsertWaitCnt so we can divide it into layers, and each layer worries about its own thing. This is only possible with proper separation of concerns.
…terleaved access analysis (llvm#205793) During interleaved access analysis, certain addresses require a no-wrap predicate to form an add recurrence and obtain the stride. However, when optimizing for size, generating SCEV runtime checks is disallowed. This patch modifies the constant stride collection when optimizing for size to only collect strides that do not require predicates. This ensures that vectorization will not blocked by disallowed predicates.
Remove the MLA commuted patterns added in llvm#198566 and canonicalise those operations in instcombine instead.
…lvm#205815) Deduce dst type for new instructions, that do the load lowering, from destination type of original load instead of from MMO. Makes a difference with extendedLLTs.
…ge (llvm#205816) In widenScalarMergeValues, WideTy is input given by target. Use same LLT kind for other types of different sizes instead of LLT::scalar. Makes a difference with extendedLLTs.
Add support for DXContainer PRIV in the ObjectYAML pipeline so it can be represented in structured YAML and round-tripped through yaml2obj/obj2yaml. PRIV part can store arbitrary user-provided binary blobs in DXContainer. Unlike other DXContainer parts, PRIV part does not have to have 4-byte aligned size. Therefore, if it is present, it is always the last section in a DXContainer. llvm-objcopy is already able to extract PRIV section. A test to verify extraction of binary from PRIV is added.
…m#205848) There is still one test remaining: LoopVectorize/X86/x86-interleaved-store-accesses-with-gaps.ll but this looks more like a phase-ordering test and should probably be handled separately.
Add a test with loads and stores with pointers based on a signed remainder (srem) of a non-negative induction variable, mirroring the existing urem test.
…g for Fortran support in lldb
…anualDWARFIndex.cpp
…ortran-compiler to dotest_args.py
…ressions not yet stored or handled
Iasonaskrpr
force-pushed
the
lldb-fortran-stable-branch
branch
from
July 27, 2026 19:36
75251ff to
1a861c5
Compare
… child array names and added GetArrayLowerBound API route to TypeSystem and CompilerType
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.