[pull] main from llvm:main - #5815
Open
pull[bot] wants to merge 999 commits into
Open
Conversation
A v2i64->v2i128 sext and zext will be scalarized to a pair of extracts and individual extends.
…SpaceAttrInterface (#217512)
…219678) Expand coverage for preserving OpenCL language address spaces across CIR textual representation and source emission before target lowering. Assisted-by: Codex / GPT-5.6 Sol
…219676) when the created shl shifts out all but one bit the and with one is not needed. proof: https://alive2.llvm.org/ce/z/MQYp6f
createSIFixControlFlowLiveIntervalsPass: The corresponding function definition was removed on August 7, 2017 in commit 3db4568. SelectADD_SUB_I64: The corresponding function definition was removed on June 22, 2026 in commit 8062e6d. hasHalfRate64Ops: The corresponding function definition was removed on January 21, 2026 in commit 2692f5e. printAbs, printClamp: The corresponding function definitions were removed on June 28, 2018 in commit c5a154d. getVCMPXNoSDstOp: The corresponding function definition was removed on February 11, 2021 in commit c16f776.
During DAG optimization, expressions like `a + a` are canonicalized to `a << 1` (`ISD::SHL X, 1`). We need to undo that if we can use adc x, x.
Fixes #219668 Building llvm 23.1.0 (and current main) for 32-bit x86 without SSE2 fails since APFloat.cpp started including libc's shared/math.h. All the errors come from the float16 headers: ``` libc/src/__support/FPUtil/BasicOperations.h:63:67: error: SSE register return with SSE2 disabled libc/src/__support/math/acosf16.h:73:14: error: invalid conversion from type '_Float16' without option '-msse2' ``` The float16 detection in float16-macros.h checks __FLT16_MANT_DIG__. Since GCC 14 that macro is defined on ia32 even without SSE2, where _Float16 is storage-only and any arithmetic or returning by value is an error. The GCC 14 release notes say to check __SSE2__ for arithmetic support instead: https://gcc.gnu.org/gcc-14/changes.html So require SSE2 on 32-bit x86 in the guard, same as the existing arm32 and riscv exclusions in this file. x86-64 is not affected (__i386__ is not defined there), and i386 with -msse2 keeps float16. Tested with gcc 16.2 targeting i686: the reproducer from the issue goes from ~340 errors to compiling clean, and a full 32-bit multilib build of llvm 23.1.0 in Yocto succeeds with this change. Since 23.1.0 is affected, I would like to request a backport to release/23.x once this lands.
Add AllocaInst::getAllocationBaseSize() and AllocaInst::isScalable(), which represent common patterns for uses which only need the size of an alloca, but can't use getAllocationSize(). This only replaces uses which are equivalent. (There are a couple of places in DebugInfo which getTypeSizeInBits(), which is not equivalent, so this patch doesn't touch them for now.)
…tructured binding (#219270) Fixes #218144 Fixes #193687 `ParseDirectDeclarator` stops right after a structured binding like `[a, b]`, since nothing can follow it — but that check only covers the unparenthesized form. For `([a, b])`, the binding gets parsed inside `ParseParenDeclarator`, and the outer `ParseDirectDeclarator` doesn't notice — it carries on into its suffix loop and parses a trailing `()` as a function declarator. `([a, b])() {}` then looks like a function definition, so `ActOnStartOfFunctionDef` gets handed a `DecompositionDecl` where it expects a `FunctionDecl`: `cast<FunctionDecl>` asserts, or segfaults later without assertions — that's #193687. (The `b;` in the report is noise; `([a])() {}` alone crashes.) This patch makes `ParseDirectDeclarator` stop as well when the parenthesized declarator turns out to be a structured binding, so nothing can follow a binding list, parenthesized or not. The declaration then takes the normal variable path and hits the diagnostics we already have — `structured binding declaration cannot be declared with parentheses`, then `expected expression` for the empty `()` — same as `[a, b]() {}` today. No Sema changes; the parser just stops building a declarator that can't exist. LLM tools were used for this contribution. I've reviewed, built, and tested the change myself before pushing.
#219606) In PR #210747 (commit 162d9f0), `addInputSegment` was changed to union segment linking flags (`linkingFlags |= inSeg->flags`) so that flags like `RETAIN` and `STRINGS` are preserved in `--relocatable` output. However, coalescing segments with differing linking flags by name alone forces one chunk's semantics onto another: - Clang emits ordinary string literals (`STRINGS`) and string literals containing embedded null characters (non-`STRINGS`) into sections named `.rodata..L.str`. When coalesced, non-mergeable segments received the `STRINGS` flag, causing downstream links to split and corrupt them. - Similarly, coalescing a chunk with `RETAIN` and a chunk without `RETAIN` forces the un-retained chunk to inherit `RETAIN`, preventing `--gc-sections` from discarding it if it is unused. Fix this by distinguishing segments by their linking flags in relocatable mode so that segments with differing flags are emitted as separate output segments rather than coalesced. Fixes: emscripten-core/emscripten#27619
Add packed widening add/sub header wrappers for the RISC-V P extension using generic vector IR.
Previously the `security.ArrayBound` checker mishandled the following C
code under non-windows platforms where `sizeof(struct Empty) == 0`:
```c
struct Empty {};
struct Empty Array[10];
struct Empty foo(void) { return Array[5]; }
```
Here the checker produced a false positive with explanation "Access of
'Array' at byte offset 0, while it holds only 0 byte" -- that is, the
checker said that this accesses the past-the-end pointer, which is
usually invalid.
This commit suppresses this false positive by saying that accessing a
zero-sized object starting at the past-the-end pointer is valid.
This is implemented by adding an `AlsoAcceptEquality` flag for
`checkBounds`. This flag will also be useful for implementing checkers
that check pointer arithmetic (where forming the past-the-end pointer is
completely valid).
This commit also includes a small grammatical fix: the explanation notes
now say "0 bytes" or "0 ... elements" instead of "0 byte" / "0 element".
…on (#215761) clang-tools-extra tests depend on the llvm-bcanalyzer CMake target, which exists in LLVM's CMake project but is not visible when Clang is built separately from LLVM. This causes CMake errors when CLANG_INCLUDE_TESTS is ON but the LLVM tools are not available. This patch introduces CLANG_TOOLS_EXTRA_INCLUDE_TESTS as a separate CMake option to control clang-tools-extra tests independently, allowing users to build Clang with tests enabled (CLANG_INCLUDE_TESTS=ON) while disabling clang-tools-extra tests (CLANG_TOOLS_EXTRA_INCLUDE_TESTS=OFF) when building Clang separately from LLVM. For backwards compatibility, CLANG_INCLUDE_TESTS=OFF continues to turn off clang-tools-extra tests as well.
Preserve flags when folding trunc (shl X, C) into shl (trunc X), C. If both ops have NUW/NSW, they can be carried over to the new shl/trunc. No major changes on llvm-opt-benchmark-nightly besides a number of preserved flags and a few minor fold changes: dtcxzyw/llvm-opt-benchmark-nightly#1083 Alive2 Proof: https://alive2.llvm.org/ce/z/EYivzg PR: #219443
These checks care about the metadata attached to an instruction or reported in a diagnostic, not the incidental numeric slot assigned while printing. Match metadata slot numbers with FileCheck patterns so numbering changes do not require unrelated test updates.
If both operands of an SDiv are known non-negative, it is equivalent to an UDiv, mirroring ScalarEvolution's handling in createSCEV. Adds m_SDiv to VPlanPatternMatch. Alive2 Proof: https://alive2.llvm.org/ce/z/NYa6Vd
…rand (#219319) `TensorAllocDemapper` reconstructs demapped level sizes for a `bufferization.alloc_tensor`/`tensor.empty` by pairing each dynamic result dimension with an entry from the op's `dynamic_sizes` operand list, popping via `ValueRange::front()`. When an `alloc_tensor` has a `copy` operand instead of explicit dynamic sizes, `dynamic_sizes` is legitimately empty — the op's own verifier requires that the sizes are implied by the copy operand and must not be specified — so `front()` was called on an empty range and asserted: ``` llvm/include/llvm/ADT/STLExtras.h:1253: Assertion `!empty() && "expected non-empty range"' failed. ``` Fix by special-casing `alloc_tensor`'s copy operand: demap the copy operand itself and forward it (with no dynamic-size operands) to a freshly created, demapped `alloc_tensor`, since the copy operand's type already fully determines the result shape. ## Testing Added the reduced reproducer from the issue to `mlir/test/Dialect/SparseTensor/sparse_reinterpret_map.mlir`. Checked on an assertions build that the reproducer aborts with the assertion above before the change and succeeds after it, and that `mlir/test/Dialect/SparseTensor` is 114/114. Fixes #216223
ProxySpec now drives shared::WrapperFunction<SPSSigT>::callAsync itself, supplying a Caller that forwards to ExecutionSession::callWrapperAsync, rather than going through ExecutionSession::callSPSWrapperAsync (which does the same thing internally). This is a step towards removing callSPSWrapperAsync (and other SPS-specific call APIs) from ExecutionSession, so that callWrapperAsync remains the only core call primitive and SPS is not baked into the core APIs.
…nterLevel (#218196) This is the first of three patches aimed at solving a non-termination problem when using DFS in the pointer-flow graph. Problem & context: Currently, the pointer-flow graph creates exactly one edge corresponding to an assignment in the source code. For example, a pointer assignment `p = q;` results in an edge `(p, i) -> (q, j)` for some pointer levels `i` and `j`. In unsafe buffer propagation, this edge encodes the meaning that if `p` is bounded, `q` must also be bounded. Additionally, if `*p/p[x]` is bounded, `*q/q[y]` must be bounded, and so on until the maximum pointer level of `p` or `q` is reached. Because of this, during DFS, a node `(p, i+1)` can reach `(q, j+1)` through the edge `(p, i) -> (q, j)`. This logic is correct only when `p` and `q` have compatible types, which is true for most cases due to standard type checking. However, this assumption breaks down with pointer casts. A cast like `a = (T)b` contributes an edge `(a, x) -> (b, y)` where `a` and `b` do not have compatible types. Consequently, the graph can contain cycles such as `(a, 1) -> (b, 2)` and `(b, 1) -> (a, 2)`. Because type information is abstracted out during DFS, we do not know the exact pointer level upper bounds to limit this growth, causing the DFS to loop indefinitely as pointer levels keep growing. Solution: To fix this, the pointer-flow graph must explicitly include the finite set of edges encoded by each assignment. Since type information is available during graph construction, we can use it to compute upper bounds. Consequently, the graph search can go back to being simple and guaranteed to terminate. As a first step toward that solution, this patch introduces a new data structure: `DeclPointerLevel`. A `DeclPointerLevel` differs from an `EntityPointerLevel` only in that it retains the AST Decl node instead of directly abstracting it to an Entity. The AST node carries crucial information, such as types, which can be used by extractors before converting `DeclPointerLevels` to `EntityPointerLevels`. First step for: rdar://183529483 --------- Co-authored-by: Balázs Benics <benicsbalazs@gmail.com>
…nsics (#219454) ad9138f removed llvm.vp.{add,sub,mul,and,or,xor,ashr,lshr,shl} but didn't update VPIntrinsicTest.cpp, which still declared/used them. The test still passes today only because UpgradeCallsToIntrinsic silently erases these now-unregistered bare declarations during parsing (no call sites to rewrite), so the test never actually exercises them. Drop them from BinaryIntOpcodes and switch llvm.vp.mul to llvm.vp.sdiv in CanIgnoreVectorLength/VPReductions. --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Move the predicate to the header so that it can be used by the macro argument name checker. Replace the incorrect local-sensitive isalnum() with ASCII-only llvm::isAlnum(). Identifier character set accepting '?' is a MC extension: https://reviews.llvm.org/D1978 While here, fix some minor bound checking related minor issues. LLM-aided
…#218207) This commit is a redesign of #198889, which introduced a non-termination bug. Problem: The current pointer-flow graph has exactly one edge corresponding to an assignment in the source code. For example, a pointer assignment p = q; results in an edge `(p, i) -> (q, j)` for some pointer levels i and j. In unsafe buffer propagation, the edge encodes the meaning that if `p` is bounded, so must `q` be; additionally, if `*p (or p[x])` is bounded, so must `*q (or q[y])` be; and so on until the maximum pointer level of `p` or `q` is reached. Therefore, during the graph search (WPA phase), a node `(p, i+1)` can reach `(q, j+1)` through the edge `(p, i) -> (q, j)`. This is correct ONLY when `p` and `q` have compatible types, which is true for most cases due to type checking. However, this assumption does not hold in the presence of reinterpreting casts—a pointer assignment `a = (T)b` (for some pointer type `T`) contributes an edge `(a, x) -> (b, y)` where a and b do not have compatible types. Consequently, one can have two such edges in the graph, causing WPA to hang on examples such as: ``` a = *b; // (a, 1) -> (b, 2) b = (char ***)*a; // (b, 1) -> (a, 2) ``` Note that during the graph search phase, type information has been abstracted out. Therefore, we do not know the exact pointer level upper bounds to limit pointer level growth. Solution: To fix this, the pointer-flow graph must explicitly include the finite set of edges encoded by each assignment. Since type information is abstracted away before WPA, this commit moves the expansion logic back into the PointerFlowExtractor, where types are still available during graph construction. The difference this makes to the PointerFlowExtractor is that the output was previously "compressed" (because one graph edge represented multiple levels) and is now "uncompressed". This simplifies WPA because the meaning of each graph edge is now straightforward. In the future, we may want to make the edge expansion optional so that it can be disabled when propagating non-type properties. Second step of: rdar://183529483 --------- Co-authored-by: Balázs Benics <benicsbalazs@gmail.com>
…o simple graph search (#218209) Because of #218207, we no longer need unsafe-buffer reachability analysis to "uncompress" pointer flow graphs. It can go back to simple DFS. Since it deals with large data, simplicity is important. In addition, unit tests for the "compressed" pointer flow graph DFS are moved to lit tests because they are no longer suitable as WPA unit tests. As lit tests, they are end-to-end tests where the extractor is involved and is responsible for generating "uncompressed" graphs. Final step of rdar://183529483
This patch unifies operator== across hash table iterators with DebugEpochBase::HandleBase::isComparableWith, performing the following safety checks: - LHS is either default-constructed or in sync with its container. - RHS is likewise either default-constructed or in sync with its container. - Both iterators belong to the same container instance and share the same state (without intervening mutations). Assisted-by: Antigravity
…219477) Follow-up test coverage for #216322, which fixed `IsProcedure()` for references to functions whose result is a plain procedure — a shape that previously aborted a production build on the `CHECK(IsProcedure(expr) || IsProcedurePointer(expr))` in intrinsic argument checking instead of reporting the declaration error flang had already recorded. The tests that landed with that fix reference the callee directly and recursively (`func-proc-result.f90`) or vary the intrinsic (`func-proc-result-intrinsics.f90`). This adds the two dimensions they leave uncovered. Assisted-by: AI
A splat gather (the same instruction in every lane) is emitted as an expensive insertion sequence. When the unique scalars of several splat gathers form a vectorizable bundle, build them as a separate subtree and emit the splat gathers as broadcasts of the vectorized value. Reviewers: bababuck, RKSimon Pull Request: #218250
This moves some of the more expensive libc jobs over the new LLVM premerge runner sets that allow dynamically setting the container. This should make them significantly faster for cold builds (e.g., new PR given cache sharing across PRs is not a thing). There was an issue with this approach originally that meant jobs would sometimes get spuriously killed but appear to succeed. That should be mitigated with some ConfigMap updates that we deployed to the cluster, but we should be on the lookout for any oddness happening with these jobs. This should also take some load off the free GitHub runners where someone opening a bunch of libc PRs in the past has consumed all the free GitHub resources leading to long delays for other jobs.
…0108) Commit 66617db bumped Sphinx to 8.2, Docutils to 0.22, and MyST-Parser to 4.0.1. When building Clang documentation with `-W`, this surfaced two breakages: 1. `ControlFlowIntegrityDesign.md`: Dangling `[^ivtbl]` footnote references without a matching footnote definition, leading to a docutils `ERROR: Too many autonumbered footnote references: only 0 corresponding footnote available` / `ERROR: Unknown target name: "ivtbl"`. 2. `ScalableStaticAnalysis/developer-docs/index.md`: `:numbered: true` caused a `ValueError: invalid literal for int() with base 10: 'true'` in MyST because `:numbered:` takes an integer depth or no argument. Fix it to `:numbered:`. AI tool usage: An AI assistant was used to help research and draft the documentation updates.
This fixes 16a770d (#220073). Buildkite error link: https://buildkite.com/llvm-project/upstream-bazel/builds?commit=16a770d01f8ef0b4bf15cb903775af64d5d9c8c7 Co-authored-by: Google Bazel Bot <google-bazel-bot@google.com>
…accompanying macros and type headers. (#219573) Testing these is a bit tricky, so: - For `getpriority`, ensure the call succeeds and round-trip the highest nice value on Linux (19). - For `setpriority`, ensure the call succeeds when setting it to the current nice. - For both, test two failure modes that are easy to stably induce.
BOLT read the entire .eh_frame up front via DwCtx->getEHFrame(), which parses and caches the CFI instruction program of every CIE/FDE in the binary for the whole run. On a large binary, this dominated file-object discovery: CFIProgram::parse accounted for ~6.5 GB and the cached DWARFDebugFrame ~6.9 GB of live memory (from 5 to 10% of total anon peak RSS). This new interface allows DebugInfo's users to optionally parse CFIs on demand, only when necessary. On BOLT, this is an important lever to manage memory utilization when processing large binaries. A real use case is also implemented in llvm-dwarfdump: it now decodes CFIs lazily, so if a user requests a dump of a specific entry, only that entry is decoded. If another entry in that section is invalid, we don't error anymore as that entry won't be decoded if the user did not request it.
…218280) Monotonic AddRecs are never less than their start value; use that in when reasoning about predicates involving an AddRec and its start value. Improves results in a few cases on llvm-opt-benchmark-nightly: dtcxzyw/llvm-opt-benchmark-nightly#996 PR: #218280
…220045) We currently assume that a partial-array destruction was a 1D array. This is incorrect, as it can obviously be a MD array. This patch comprehends the destruction across the array by using the same begin/end iterators, but deleting these as element nodes. Classic codegen does a full descent into the array types to do this destruction, but I believe that is a side-effect of how it is going through it. Treating arrays as contiguous and flattening the iterators is effectively identical. Note: Claude helped me extensively on the test, I believe all the check-lines are correct, but I also pushed to make sure we got the full structure checking correctly, so I hope this shows the differences above properly.
SCEV models ptrtoaddr via getPtrToAddrExpr. Mirror that in getSCEVExprForVPValue. ptrtoint stays unmodelled, as createSCEV returns an unknown for it. Adds m_PtrToAddr to VPlanPatternMatch.
This patch re-generate some analysis RISCV tests by automatic update scripts to make tests easier to update.
Groundwork for #196388 [sanitizer_common] Add operator new chain-handling framework Implement the operator new wrapper machinery required by [new.delete.single]/3+/4 in shared sanitizer_common files so every sanitizer can reuse it (avoids ~130 lines of duplication). sanitizer_new_handler.h provides three main templates in namespace __sanitizer (plus a NORETURN InvokeOnExhausted wrapper used internally): * RunNewHandlerChain<Alloc>(alloc) Runs std::get_new_handler() in a loop until either the allocation succeeds or the chain is exhausted (returns nullptr). * NewImplThrowing<Alloc, OnExhausted>(alloc, on_exhausted) Throwing operator new: runs the chain; on exhaustion either throws std::bad_alloc (AllocatorMayReturnNull()=true opts into standards-conformant throw) or invokes on_exhausted (default; historical abort-on-OOM). * NewImplNothrow<Alloc, OnExhausted>(alloc, on_exhausted) noexcept Nothrow operator new: per [new.delete.single]/4 behaves as-if the throwing form is called within a try/catch converting any exceptions to a nullptr return. NOTE: Windows builds do not support exceptions, so the throwing std::bad_alloc behavior described above is converted to an invocation of on_exhausted(); a user new_handler that throws on Windows trips the noexcept on NewImplNothrow and aborts via std::terminate. NOTE: The framework auto-detects exception support via the standard __cpp_exceptions feature-test macro: when a consuming TU is compiled with -fno-exceptions, the throw/try-catch logic is compiled out and the framework collapses to the abort path (same shape as Windows). This means TUs do not have to be built with -fexceptions, and a -fno-exceptions adopter incurs no std::bad_alloc symbol dependency. When -fexceptions IS used, instantiating the throwing-form template introduces a runtime dependency on std::bad_alloc — adopters must link a C++ ABI library (libstdc++ / libc++abi) into the resulting runtime. sanitizer_new_operators.inc builds the eight standard OPERATOR_NEW_BODY* macros on top of these templates. A consuming sanitizer defines six ingredient macros (a stack-trace setup, a report-OOM invocation, and four alloc helpers) and then includes the file. The resulting OPERATOR_NEW_BODY / OPERATOR_NEW_BODY_NOTHROW / OPERATOR_NEW_BODY_ARRAY / ... / OPERATOR_NEW_BODY_ALIGN_ARRAY_NOTHROW macros can then be used directly as the bodies of the eight operator new overrides. NFC. No consumer yet — this is a prerequisite for a follow-up that restructures compiler-rt/lib/asan/asan_new_delete.cpp to use the shared framework. Assisted by: Claude Opus 4.7 -------------------- Further context for the PR summary... Here's a breakdown of framework applicability and the work required to deploy it. ``` Sanitizer | Delta SLOC | aligned | OOM-null | adoption | notes -----------+------------+---------+----------+-----------------+---------------------- asan | -43 | yes | yes | DONE | framework consumer hwasan | -50 | yes | no | easy + prereq | needs may_return_null memprof | -25 | yes | no | easy + prereq | needs may_return_null msan | -25 | yes | no | easy + prereq | needs may_return_null dfsan | -25 | yes | no | medium + prereq | needs may_return_null nsan | -25 | yes | no | medium + prereq | needs may_return_null tsan | -30 | yes | no | medium + prereq | user_alloc shim too lsan | - | no | no | medium | only 4 of 8 overloads Delta SLOC = code size effect of applying the framework. All but asan are estimated. aligned = has std::align_val_t overloads OOM-null = internal alloc returns nullptr on OOM (vs. abort) adoption = effort to wire to the framework prereq = per-sanitizer commit to plumb "may_return_null" behavior and enabling exceptions in the "*_new_delete.cpp" TU. dfsan/nsan also need a CXX slice defined in the build infrastructure. ```
…FC (#220115) The first immediate is the destination memory index and the second is the source memory index according to the WebAssembly specification and `LowerMemcpy` in `WebAssemblyISelLowering.cpp`.
Fixes #194948 This PR adds the TextureCubeArray type to HLSL. A rather straight-forward change since TextureCube and array textures were already implemented before. There are a couple test changes to accomodate the combination of cube with array textures. Assisted by: Claude Opus 5 --- <sub>Stack created with <a href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
Example:
```fortran
!$acc atomic capture
nSmall = nSmall + 1
indx = nSmall
!$acc end atomic
```
acc.atomic.capture always generated a cmpxchg loop, while
acc.atomic.update already mapped a simple binop to atomicrmw. On a
partition loop with 204800 threads contending on one scalar, the CAS
retries dominate.
Fix: give the capture conversion the same atomicrmw path. atomicrmw
returns the old value, so `{read, update}` stores it directly and
`{update, read}` reapplies the binop to it.
Related: #179278 This patch adds initial support for CUDA built-in texture types in CIR for device-side compilation. CUDA texture references are lowered to the NVPTX device-handle representation (`i64`), matching existing Clang CodeGen behavior. ## Changes - Add `getCUDADeviceBuiltinTextureDeviceType()` target hook to `TargetCIRGenInfo` - Implement NVPTX texture lowering in `NVPTXTargetCIRGenInfo` - Handle CUDA built-in texture types in `CIRGenTypes::convertType` - Add initial CUDA texture variable registration bookkeeping in `CIRGenNVCUDARuntime` - Add CIR CUDA test coverage for device-side texture lowering ## Notes - This patch implements initial device-side texture type lowering support - Full CUDA runtime texture registration remains unsupported - Texture registration metadata such as texture type and normalized mode is left for follow-up work - TBAA handling for surface/texture types is left for follow-up work
…9085)" (#220124) This reverts commit 459dffa The new test added in the original PR uses 'clang-apply-replacements' conditionally now. It checks if the tool is available before using it. When the tool is not there, it only checks against replacement offsets and texts. Final step of: rdar://185840466
This fixes 7651d2d (#219552). Buildkite error link: https://buildkite.com/llvm-project/upstream-bazel/builds?commit=7651d2dec29ea98dad2ba59fb7b5b480eaa1f23e Co-authored-by: Google Bazel Bot <google-bazel-bot@google.com>
…te subtrees" This reverts commit e7e0985 to fix buildbots like https://lab.llvm.org/buildbot/#/builders/17/builds/17224 Reviewers: Pull Request: #220134
Fixes #218535 UAV texture resources were using the SRV version of the .Load() method and resulted in no matching member function calls when attempted to be used. This PR fixes that issue by adding addRWTextureLoadMethods() to HLSLBuiltinTypeDeclBuilder.cpp and fixing the codegen for BI__builtin_hlsl_resource_load_level to handle UAVs. Assisted by: Claude Opus 5 --- <sub>Stack created with <a href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
BOLT read the entire .eh_frame up front via DwCtx->getEHFrame(), which parses and caches the CFI instruction program of every CIE/FDE in the binary for the whole run. On a large binary, this dominated file-object discovery: CFIProgram::parse accounted for ~6.5 GB and the cached DWARFDebugFrame ~6.9 GB of live memory. Yet the CFI programs are only consumed in CFIReaderWriter::fillCFIInfoFor, and only for the functions BOLT actually disassembles. discoverFileObjects itself needs nothing but each FDE's address and range for function-boundary checks. Here we parse .eh_frame for its index only, and decode each function's CFI program on demand, lazily, only for the functions that really need it. In a large binary, DWARFDebugFrame::parse drops from 6922.2 MB to 587.6 MB, the residual being the lightweight FDE/CIE index (entries without instruction programs), and readSpecialSections falls from 7078.7 MB to 738.6 MB on the tested binary for which BOLT's RSS is about 80-120GB.
…ze. (#219221) Add regression tests for SLP vectorization of insertvalue chains over homogeneous structs ({ i64, i64 } and { i32, i32, i32, i32 }). The tests capture the current behavior prior to the fix, where getVectorElementSize() uses the aggregate's total size, potentially limiting the maximum vectorization factor on targets with a bounded TTI::getMaximumVF(). A follow-up patch will fix getVectorElementSize() to recurse through InsertValueInst and update these CHECK lines to reflect the correct vectorized output. Tests added: - llvm/test/Transforms/SLPVectorizer/RISCV/insertvalue-elt-size.ll Co-authored-by: Aditya-Chaudhary1 <aditya.chaudhary1@ibm.com>
…219884) When generating SUBS to un-fuse the Armv9.6 Compare-and-Branch immediate variants CBWPri and CBXPri during if-conversion, we missed to constraint the register classes, leading to a verifier crash.
Adds omitted 128-bit to 256-bit patterns for `sign_extend_vector_inreg`, including `v16i8 -> v4i64` and `v8i16 -> v4i64`, which will generate by the combination of `icmp + or/and/xor + zext/sext`, all related tests are added. Fix: #219224
Allow the OR/AND -> V_PERM DAG combine for values, even if they are uniform. Co-authored by Brendon Cahoon and Cursor
Allow clients to pass symbol names as SymbolStringPtrs (in addition to StringRefs).
) llvm.pseudoprobe is modeled as accessing inaccessible memory, so mayReadFromMemory()/mayWriteToMemory() return true even though the intrinsic carries no real memory dependence. An otherwise vectorizable early-exit loop is therefore rejected as soon as it contains a pseudo probe. This patch skips pseudo probes in isVectorizableEarlyExitLoop(), isReadOnlyLoop() and areAllLoadsDereferenceable() so the three checks agree and such loops vectorize as they would without pseudo probe instrumentation. Discussion: https://discourse.llvm.org/t/csspgo-unblocking-pseudo-probe-safe-optimizations/90946
Fixes #219542 Refactors texture type declaration in `HLSLExternalSemaSource.cpp` so that new texture types can more easily be added without adding a bunch of new helper functions. This is accomplished with the introduction of a new `TextureTypeInfo` struct to record the properties of each texture type, as well as its capabilities indicated by the `TexCap` bitmask enum. Adding a new texture type to be declared should, in most cases, only require appending a new entry to the static `TextureTypes` array of `TextureTypeInfo`. Assisted by: Claude Opus 5 --- <sub>Stack created with <a href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub> --------- Co-authored-by: Helena Kotas <hekotas@microsoft.com>
A getNode helper builds its lookup ID by hand; matching it later rebuilds one from the node with AddNodeIDCustom. Where the two disagree the compare always fails and the node never CSEs. Fix whichever side is wrong: the labels, DEACTIVATION_SYMBOL, GET/SET_FPENV_MEM and EXPERIMENTAL_VECTOR_HISTOGRAM have no case; getLifetimeNode keys on a frame index operand 1 already carries, getStridedLoadVP on the result type instead of the memory type, and getPseudoProbeNode drops the attributes its case profiles. Ask AtomicSDNode instead of an opcode list stale since ATOMIC_LOAD_FADD, and add the two opcodes its own classof was missing. AddNodeIDCustom now takes the opcode to profile under, so MorphNodeTo's pre-morph lookup keys on what the morph produces. Machine opcodes profile nothing: the morph overlays MachineSDNode's memory references on the fields the MemSDNode checks read. A duplicate load now CSEs in merge_stores_dereferenceable.ll. Aided by Opus 5
Vector add/mul and scalar floating-point min/max are already marked as commutable. This extends the same property to floating-point vector min/max, allowing better WebAssembly register stackification. Should avoid any locals as per what's happening now ``` .local v128 call red local.set 0 call green local.get 0 f32x4.min ```
…deallocs (#220059) This is a follow up to [#206614](#206614), which made `allocate(foo(i)%arr(...))` inherit `foo`'s CUDA memory attribute, but did not add the equivalent inheritance for `deallocate(foo(i)%arr)`. The deallocation still lowered to an inlined `fir.freemem`, so memory obtained from a CUDA allocator was released with libc `free()`. The allocate side already walked the `DataRef` chain for a CUDA-attributed parent, but the helpers were private to `AllocateStmtHelper` and unreachable from the deallocate path. This patch hoists `findCUDAAttrInDataRef` to file scope, adds `getCUDAAttrParentSymbol(AllocateObject)` beside it, and reduces the existing member to a thin wrapper. The allocate behavior is unchanged. `genDeallocate` gains an optional `cudaSymbol` used only for the CUDA decisions (`isCudaSymbol` and the `genCudaDeallocate` call). `genDeallocateStmt` supplies the parent symbol, which is non-null only for a structure component whose parent carries CUDA attributes. Lowering now emits `cuf.deallocate ... {data_attr = #cuf.cuda<...>}` for the component where it previously emitted `fir.freemem`, with no `fir.freemem` remaining under `-gpu=managed`, `-gpu=pinned` or `-gpu=unified`. Also extended test coverage in `cuda-allocatable-component.cuf` with a direct `managed` parent and a `device` attribute reached through an intermediate parent.
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )