[pull] main from llvm:main - #1719
Merged
Merged
Conversation
…213658) ### summary This PR is a follow-up to #207189 and adds CIR lowering support for the eight AArch64 scalar signed and unsigned saturating subtract intrinsics. It reuses the common Neon SISD lowering infrastructure introduced by #209389. The legacy CodeGen tests are migrated to the ACLE-organized subtraction test file with corresponding CIR and LLVM checks. Assisted by : gpt5.6-sol high
#213968) There was a discrepancy compared to SDAG when G_PTR_ADD was being matched and there was no nuw flag check. In case of G_PTR_ADD, nuw flag comes from inbounds flag on getelementptr. For reference, SDAG does not have pointers so PTR_ADD is integer ADD in SDAG.
When creating SCEV checks as part of loop vectorisation we often generate overflow checks, which leads to lots of duplicated calls to the umul_with_overflow intrinsic. These calls should be cleaned up during codegen. However, it is unfortunate that the current LLVM method of calculating the cost of IR in a block involves looping over each instruction and adding the costs individually with no thought to the trivial CSE or DCE optimisations that would take place. In the absence of a more sophisticated method of cost analysis, for now I've chosen to explicitly CSE these overflow checks during SCEV expansion.
The getPMOVMSKB helper has been used to generate MOVMSKPS/D cases as well for some time.
Emit the check at the block's first insertion point instead of before the terminator. SCEV expansion reuses any dominating instruction, so at the terminator it could pick up body scalars that are later moved into the vector block and deleted, causing a crash. Reviewers: Pull Request: #214211
…ting mode (#208828) Implement the gfortran-style `-ffpe-trap=<list>` option, which sets the initial floating-point exception halting mode for the main program unit. The Fortran 2023 standard (17.6) permits the initial halting mode to be processor defined, so honoring this at program start is conforming. `<list>` is a comma-separated set of exception mnemonics: `invalid`, `zero`, `overflow`, `underflow`, and `inexact`, corresponding to the IEEE_FLAG_TYPE values IEEE_INVALID, IEEE_DIVIDE_BY_ZERO, IEEE_OVERFLOW, IEEE_UNDERFLOW, and IEEE_INEXACT. As a non-standard, gfortran-compatible extension, `denormal` halts on the x86 denormal-operand exception. An empty list or the value `none` disables halting, and the last `-ffpe-trap=` on the command line wins (allowing an earlier request to be overridden). Changes by component: - clang/Driver: give `-ffpe-trap=` FlangOption/FC1Option visibility and a one-line HelpText plus a detailed DocBrief (moved into f_Group); forward the flag to -fc1. Emit a target-based warning when halting control is unavailable (non-x86 and non-Linux targets), and a denormal-specific warning on non-x86 targets. The check is intentionally conservative and only ever under-warns; the runtime remains authoritative. - flang/Frontend: parse the list into a LangOptions bitmask (FPExceptionTrapKind), error on unknown mnemonics, and propagate the mask to the lowering options. - flang/Lower: genMain() injects a call to _FortranAEnableFPETraps into the main program unit only (after ProgramStart, before _QQmain), so the mode persists across procedures as required by F2023 17.6. - flang-rt: add EnableFPETraps(), which enables halting only for the exceptions whose halting control is supported on the target (IEEE_SUPPORT_HALTING, F2023 17.11.40); it is a no-op elsewhere. Testing: - Driver tests for forwarding, "none"/empty, last-wins, bad-argument errors, and the unsupported-target / denormal warnings. - FIR lowering tests for the emitted call and constant mask, including a negative test that a non-main compilation unit emits no call. - flang-rt execution tests that verify each exception (invalid, zero, overflow, underflow, inexact, denormal) actually terminates the program with SIGFPE, plus a selectivity test that an unrelated enabled trap does not halt. The denormal execution test is gated to x86. These changes were generated with the assistance of AI tooling and have been reviewed, tested, and validated by the author. Resolves #198657
) E.g. #214159 PR is missing labels
So that later arguments get the correct register alignment https://godbolt.org/z/oaEf4Thvx On current clang the aligned struct starts in `o1`, but with GCC it is aligned and starts in `o2`. In practice I think only `float` could hit this (not an int, not an aggregate, smaller than 64 bits).
…zedLoop (#208500) LoopVectorize queried getUnrollingPreferences after VPlan execution, when the vector loop had already been created. If the target hook queries ScalarEvolution, this populates the SCEV caches with expressions for the new loop and changes which existing values SCEVExpander reuses later. This is exposed by #205102, where the new AArch64 unrolling preferences cause unrelated LoopVectorize tests to produce different IR. UnrollVectorizedLoop is a target-wide preference. Query it on the original loop before VPlan execution and before its SCEV information is forgotten. This prevents the preference query from polluting subsequent SCEV expansion.
Harden ``llvm-profgen``'s ``perf script`` invocation for ``--perfdata``: report launch/exit failures, and clear redirect files between the two invocations so stale stdout/stderr cannot leak. Cover both with lit tests that inject a mock ``perf`` via ``PATH``. Assisted by GPT-5
Only replace the event operand with OpConstantNull when it is actually a null constant This complies with spirv-val expectations
Combine: orr(umin(A, 1), umin(B, 1)) -> umin(orr(A, B), 1) To remove a redundant UMin. This pattern has been observed with reduction chains of multiple ORRs of UMin(x, 1), where only one final UMin(x, 1) is necessary for truncation.
#214083) The 5.1 spec lists PRESENT as an alternative in a 'motion-modifier'. The other alternatives are mapper and iterator. These already exist as separate modifiers, so 'motion-modifier' would best be expressed as a modifier group. While modifier groups are not implemented yet, borrow 'present-modifier' from the 6.0 spec. The 'expectation' modifier only existed in 5.2, it was replaced by 'present-modifier' in 6.0.
…oarray #193157 (#213890) This PR fixes the behavior reported in issue #193157. The coarray_handle was only defined if a call to mif.alloc_coarray was present. If a call to mif.dealloc_coarray was encountered without a prior call to mif.alloc_coarray, then the coarray_handle was missing, and therefore llvm.address_of pointed to a non-existent address, which is not allowed. We now define a coarray_handle that has not been allocated by PRIF for each coarray variables.
…#210871) Fixes #122058. ## Overview Attribute `alloc_align`'s TableGen subject accepts any declaration satisfying `HasFunctionProto`, but `AddAllocAlignAttr` unconditionally casts the declaration to `FunctionDecl` (in `Sema::AddAllocAlignAttr()`). Since there exist `Decl`'s that have an underlying `FunctionProtoType` but are not `FunctionDecl` (e.g. function pointer variables and parameters), the unconditional `cast<FunctionDecl>` is too narrow and leads to a crash for `Decl`s that are meant to be compatible with the `alloc_align` attribute. For example, trying to compile `C` file ``` void *(*allocator)(unsigned long long) __attribute__((alloc_align(1))); ``` with ``` > clang example.c -fsyntax-only ``` (with assertions enabled in the build) crashes with ``` Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file Casting.h, line 572. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and dumped files. ... ``` I remove the over-restrictive `cast<FunctionDecl>`, extend parameter-range lookup through `TypeSourceInfo` for pointer-like function declarations, and add clang lit tests for function pointers, member pointers, references, blocks, qualified pointers, and Objective-C methods. ## Solution The TableGen definition of the `alloc_align` attribute ```cpp def AllocAlign : InheritableAttr { ... let Subjects = SubjectList<[HasFunctionProto]>; ... } ``` from `clang/include/clang/Basic/Attr.td` guarantees that any `Decl` reaching the function ``` void Sema::AddAllocAlignAttr(Decl *D, const AttributeCommonInfo &CI, Expr *ParamExpr) {...} ``` in `clang/lib/Sema/SemaDeclAttr.cpp` has an underlying `QualType` that is a `FunctionProtoType` (and thus a valid candidate for the `alloc_align` attribute). Note that the `FunctionProtoType` may not be the `QualType` of the `Decl` instead, but rather wrapped inside pointer, reference, and so on. Therefore, we can completely drop the `cast<FunctionDecl>(D)` from `Sema::AddAllocAlignAttr(Decl *D, const AttributeCommonInfo &CI, Expr *ParamExpr)`. However, this introduced a subtle problem. In `Sema::AddAllocAlignAttr(Decl *D, const AttributeCommonInfo &CI, Expr *ParamExpr)`, after `Decl D` has been confirmed to have a `FunctionType` with return type `PointerType`, there is logic to check that the relevant parameter `ParamExpr` is valid as an input to `__attribute__((alloc_align(N)))`, and if it is not, we emit diagnostic: ``` Diag(ParamExpr->getBeginLoc(), diag::err_attribute_integers_only) << CI << getFunctionOrMethodParamRange(D, Idx.getASTIndex()); ``` The function `getFunctionOrMethodParamRange(const Decl *D, unsigned Idx)` from `clang/include/clang/Sema/Attr.h` calls `getFunctionOrMethodParam(const Decl *D, unsigned Idx)` (from the same file), which only handles declaration types that directly own a parameter list, specifically `FunctionDecl`, `ObjCMethodDecl`, and `BlockDecl`. But `getFunctionOrMethodParam` may be reached by `Decl`'s that have an underlying function (more precisely `hasFunctionProto(decl)` is true) but are not one of the three currently handled (and we do want to handle them, they are valid cases). Thus, I also modify `getFunctionOrMethodParam()` to (if we are not dealing with a `FunctionDecl/ObjCMethodDecl/BlockDecl`) use the TypeSourceInfo of the `Decl` to get a `FunctionProtoTypeLoc` for the underlying function, which in turn gives us access to the parameter declarations. More specifically, the process is: 1. Obtain the declaration's `TypeSourceInfo`. 2. Start from its unqualified `TypeLoc`. 3. Unwrap a pointer, member pointer, reference, or block pointer. 4. Find the underlying `FunctionProtoTypeLoc`. 5. Retrieve the indexed `ParmVarDecl`. The fallback logic is best-effort and can recover parameter declarations when the function prototype exists in the declaration's own `TypeSourceInfo`. It can handle: - ordinary function-pointer declarators at file scope, local scope, in fields, or as parameters, including top-level-qualified pointers; - member-function pointers (e.g. `int (someclass::*memberfunc)(...) = ...;` in cpp) - references to functions (e.g. `int (&ref)(int, int)` in cpp) - block-pointer declarators (`int (^block)(int);` in objective) - typedef and type-alias declarations that directly have the function prototype (e.g. `typedef void *(*f)(int);` in cpp) <!--for recovery `FieldDecls` (seen for example in including the glibc header in the reproducer from the issue), and for valid declarations such as func pointers and Objective C methods.--> ## Testing Added clang lit tests for: - a valid file-scope function-pointer declaration and the recovery `FieldDecl` from #122058, to check that they dont crash - parameter validation for function-pointer and member-function-pointer declarations (checking both valid integral and invalid non-integral cases) - valid and invalid parameter types on Objective-C methods - diagnostic source ranges for filescope function pointers, member-function pointers, function references, and block pointers. *** AI note: Used gpt-5.6-luna to help generate `CHECK:`'s in the new clang lit tests (giving it the expected output for example what source code should be underlined, to generate the `{[[@Line-...]]...` syntax). Also used it to better understand the hierarchy and relationship between `*Loc` classes and the interface they expose. --------- Co-authored-by: Mimis Chlympatsos <mimischly@MIMIS-MAC-120.local> Co-authored-by: Aaron Ballman <aaron@aaronballman.com> Co-authored-by: Mimis Chlympatsos <mimischly@gmail.com>
#213779) When a source's stack frame is not live on the current stack the `UseAfterLifetimeEnd` checker emitted a false positive. Such sources outlive the returned value, so they are not dangling stack sources. This led to multiple false positives when I ran the `UseAfterLifetimeEnd` checker on the LLVM project. --------- Co-authored-by: isuckatcs <65320245+isuckatcs@users.noreply.github.com>
`#cir.record_layout` carries `record_align`, which CIRGen fills from `ASTRecordLayout::getAlignment()` and consumers read as an `llvm::Align`. That constructor asserts the value is a non-zero power of two, so hand-written CIR naming any other alignment aborted the tool rather than reporting a parse error. A zero tripped the non-zero assert and a 3 tripped the power-of-two one, both inside `llvm::Align` with no indication of which attribute was at fault. Verify the field where it is parsed. Values CIRGen emits are already well-formed, so this only affects hand-written input. Assisted-by: Cursor / claude-opus-5
Block-local origins were only discarded in `join`, which the dataflow driver skips when a successor's in-state is seen for the first time, and therefore always skips for a block with a single predecessor. In straight-line code the block-local map was inherited down the whole chain and never cleared, so it accumulated every expression origin in the region. Drop them in a new `exitBlock` hook instead, which runs on every edge. This also keeps in-states canonical, so state comparison no longer sees a spurious difference between a first-visit in-state and a joined one. The per-program-point states the checker queries are unaffected; only the state propagated across block boundaries changes. LoanPropagation time below, median of 5-7 interleaved runs of a baseline and a patched binary. Synthetic cases are from clang/test/Analysis/LifetimeSafety/benchmark.py: | case | before | after | delta | |-------------------------|--------|--------|--------| | switch_fan_out (N=4000) | 7.62 | 5.35 | -29.8% | | nested_loops (N=200) | 0.78 | 0.55 | -28.9% | | merge (N=5000) | 8.58 | 8.21 | -4.3% | | cycle (N=200) | 164.19 | 162.95 | -0.8% | Real-world translation units: | translation unit | before | after | delta | |---------------------------|--------|--------|--------| | ByteCode/Disasm.cpp | 22.34 | 18.21 | -18.5% | | X86/X86ISelLowering.cpp | 49.31 | 42.19 | -14.5% | | Sema/SemaExprCXX.cpp | 40.01 | 36.78 | -8.1% | | TargetBuiltins/ARM.cpp | 45.68 | 43.24 | -5.3% | Gains are concentrated in blocks with a single predecessor, where `join` never ran. Other phases are unchanged within run-to-run noise, and peak RSS is unchanged. LoanPropagation is 5-14% of the whole analysis, so its total effect there is -0.8% to -1.4%. Assisted-by: Opus 5.0 --------- Co-authored-by: Gabor Horvath <gaborh@apple.com>
This patch primarily fixes the case of a scoped enum with a boolean type in CIR, which we assume is an 'int' type, whereas this one case, that is not true. Rather than change the Dialect for what amounts to a very rare case, we've instead opted to just coerce the bool type into a 1 bit int type, so that all our passes will consider it the same as the rest of the switches, and not have to special-case the 'bool' types. AS A DRIVE-BY: I discovered that classic-codegen manages to assert on llvm::isUIntN in the case where the storage of a range for GNU-range-switch is less than 7 bits, so bit-int could possibly hit this too with gnu-range. This patch would fix any case (as the test for the 'shortcut' is for <64).
Modify the ABI of `_Complex` so that it matches GCC for all types, specifically: - On SPARC, a `_Complex` value with an integer element type is now passed and returned packed into the one or two integer registers it fits in, matching GCC. Clang previously passed such a value indirectly and returned it with one part per register. `-fclang-abi-compat=23` restores the previous behavior. - On SPARC64, a `_Complex char` or `_Complex short` is now right-justified in its slot in the parameter array, like every other scalar narrower than a slot, rather than left-justified the way a small struct is. `-fclang-abi-compat=23` restores the previous behavior. Complex integers are a GNU extension, but generally clang is compatible with GCC. Really, you might as well be, deviating can only bite users. I've now validated the implementation with https://github.com/folkertdev/powerpc-complex-abi-validation which compiles various signatures using `_Complex` with GCC and Clang and checks that values make it from one side to the other. related: - rust-lang/rust#154023 - #208917 - #212119
…in permissive mode (#214212) In `-Wlifetime-safety-permissive` mode, suppress dangling field warnings (`-Wlifetime-safety-dangling-field`) when `this` or the escaping field declaration is captured by a lambda within the function. This accounts for common RAII field resetters that clean up dangling pointers on scope exit. ### Motivating Example Dangling field analysis can report false positives when an RAII field resetter (such as `absl::MakeCleanup` or `absl::Cleanup`) captures `this` or the field to reset the pointer before function exit: ```cpp struct TimeServerInstance { Handler* handler_; void init() { Handler local_handler; handler_ = &local_handler; // False positive: intra-procedural analysis does not evaluate RAII // cleanup lambdas that reset dangling fields on scope exit. absl::Cleanup cleanup = [this] { handler_ = nullptr; }; } };
Perform scalar FMUL with bf16 more efficiently. Utilize v2bf16 patterns. Signed-off-by: John Lu <John.Lu@amd.com>
For example, `vzext.vf2` followed by `vzext.vf4` should be combined into `vzext.vf8` if proper conditions are met.
`cosh(x)` is `>= 1.0` or NaN for all inputs. So I have marked `cosh` as returning a value that is not-negative, not-subnormal, and not-zero. This addresses the `cosh` portion of #211686 (but not the `acos` portion). AI disclosure: I used OpenAI Codex (GPT-5.6-sol) to help generate the test updates, which I reviewed and tested locally.
Add bazel definitions for the BOLT instrumentation and hugify runtime libraries.
…13812) `KnownFPClass` incorrectly assumed that a non-NaN input to `asin` or `acos` implies a non-NaN result. However, both `asin` and `acos` can return NaN from a finite input when `|x| > 1.0`, such as `asin(2.0)` or `acos(2.0)`. I have fixed this by removing the calls to `Known.propagateNaN(KnownSrc)`, which incorrectly propagated that `asin(non-NaN) == non-NaN`. I discovered this while working on #211686. The same issue was previously noted in a post-merge review comment on #190609 (comment) AI disclosure: I used OpenAI Codex (GPT-5.6-sol) to help generate the test updates, which I reviewed and tested locally.
Allow uses of SVE instruction for fixed length vector interleave intrinsic that can not be lowered through NEON.
…zed (#214037) ## Overview `rpc::Process::notify()` guards `doorbell->value` but then unconditionally dereferences `doorbell->mailbox`. The two are not initialized together. The AMDGPU offload plugin sets `value` to the address of a field in its HSA signal, so it is never null, while `mailbox` is that signal's `event_mailbox_ptr`, which is zero unless the signal is interrupt-backed: ```c++ Value = reinterpret_cast<uint64_t *>(&Doorbell->value); Mailbox = reinterpret_cast<uint64_t *>(Doorbell->event_mailbox_ptr); ``` The existing guard can therefore never fire on AMDGPU, and `notify()` stores to a null address. Guard the mailbox store instead, which matches the intent stated in 4961700 that the interrupt is "completely optional, as it is ignored if uninitialized". The check is inside the block rather than in the outer condition because `value` is the pending-work counter the server observes; skipping the increment starves a polling server instead of fixing anything. ## Testing - (AI assisted) New unit test covering a partially initialized doorbell and an unconfigured one; the former segfaults without this change. Also verified end to end on MI350X (gfx950, ROCm 7.14, clang 23) by rebuilding both consumers of this header, `libc.a` and the OpenMP DeviceRTL, with and without the change. In-kernel `malloc`, in-kernel `printf`, and a Fortran array-section assignment all fault before it and complete with correct results after.
…14259) Both OMP and OpenACC count on being able to reach their end-annotation token in order to properly recover from errors/leave the parser in good shape. This works well for 'free' functions. However, when we do a pre-parse so we can delay-evaluate member functions, a stray end-brace can end up matching the end of the function. As a result, the examples in the test would have that brace ending with an EOF, which confused both of the pragma languages. This patch teaches the ParseCXXInlineMethods functionality to ignore any braces/etc inside of a OpenACC/OpenMP pragma for the purposes of matching, since these shouldn't count towards that scoping anyway. Fixes: #214195
Restore the BF16 semantic types omitted by the extended LLT migration and preserve packed vector legalization.
…ntal intrinsics (#214040)
When every copyable model of an edge is skipped because the user is itself a copyable lane, the instruction's own schedule data still carries the def-use dependency counted by calculateDependencies. Release it instead of returning early just because copyable data was found. Fixes #213369 (comment) Reviewers: Pull Request: #214283
Summary: This PR attempts to unify the atomic scope handling between clang and LLVM. The difficulty is that clang emits ABI-mandated integers for these while the backends use arbitrary strings. We still want the flexibility of these being arbitrary strings, but we should put this in a single source of truth. The main motivation is so IR passes can determine which scope clang used when creating these, and so future additions all go in one place. This was modeled after the AtomicOrdering.h file.
The previous constructor left these fields undefined. This updates it to initialize the fields explicitly and switch to default constructor. Making sure that on every use the fields are automatically initialized.
…checks` (#214046) AI-disclaimer: created using AI, then reviewed/manually cleaned up.
…214007) Fixes #213734 --- ## Summary At `-O0`, WebAssembly FastISel could miscompile programs that sign-extend an i1 value to i64 when the `+sign-ext` target feature is enabled. The bug was introduced in LLVM 23 by the FastISel sign-ext optimization (#179855). For `sext i1 to i64`, FastISel fell through its switch without emitting any instruction and returned an undefined register. Code that uses this pattern to adjust integer division results (such as floor division) could then compute the wrong answer. The issue reporter saw `-1` instead of the correct `-2`. This patch restructures `signExtend()` so i8, i16, and i32 still use their native WebAssembly sign-extension instructions, while i1 goes through the existing generic path: sign-extend in i32 via shifts, then `i64.extend_i32_s`. ## Test plan - [x] Added `i64_extend1_s` to `signext-inreg.ll` (covers FastISel and DAG, with and without `+sign-ext`) - [x] Verified issue repro: `llc repro.ll -O0` now returns `-2` (was `-1`); `--fast-isel=false` still returns `-2` - [x] `./bin/llvm-lit -j1 ../llvm/test/CodeGen/WebAssembly` <img width="3072" height="1920" alt="image" src="https://github.com/user-attachments/assets/0944887b-54b8-4e8d-8291-a64b03ff3786" /> --------- Signed-off-by: Gaurav Chaudhary <chaudharygaurav2004@gmail.com>
…tomicrmw (#211497) After #190716, we now allow integer vector `atomicrmw`, and these should be expanded using `cmpxchg` loops. Currently, these are throwing an assert in `NVPTXISelLowering.cpp`: `assert(Ty->isIntegerTy() && "Ty should be integer at this point");` here I fix that. Second, we are handling partword integer vector `cmpxchg` loops (namely, `<2 x i8>` incorrectly in some cases. The first issue is for `Add` and `Sub`, where we optimize by performing the operation on the word size. This works because even if we overflow or underflow the partword, we handle this by masking back on the the other original loaded bits that we are not operating on. We can't, however, implement a `<2 x i8>` add using a scalar 32-bit add, because the vector variant overflows lane-wise, which can't be emulated with a scalar 32-bit add. I think there might be a way to implement it with a `<4 x i8>` add, but I'm not sure if it's worth it, maybe I'll add that in the future. For now, just go the normal route of extracting out the `<2 x i8>` from the word and performing the `Add` and `Sub` on `<2 x i8>`. Third, for `widenPartwordAtomicRMW`, this operates on `Or`, `Xor`, `And`, all of which the corresponding scalar operation works the same as the integer vector operation. So we can implement these using the scalar word-size operation, we were just missing a `bitcast` from the vector to the scalar.
…ude (#191004) Introduce Preprocessor::isNextPPTokenHeaderNameOrOneOf to centralize lookahead logic for header-name formation and token classification under ParsingFilename mode. Refactor handling of C++20 module/import contextual keywords and LexHeaderName to use the new helper, ensuring consistent behavior between `import` and `#include`. Try to form a valid header-name token during lookahead. If that fails and the next token is not one of the expected alternatives, treat it as not an `import` directive or as an invalid `#include` (missing <FILENAME>/"FILENAME"). ```cpp #define FOO foo> #include <:FOO ``` Now such cases are rejected as expected. Also adjusts peekNextPPToken to properly support dependency directive lexers. No functional change intended for valid code; improves correctness and consistency in edge cases involving header-name lexing. Fixes #190693. --------- Signed-off-by: yronglin <yronglin777@gmail.com> Signed-off-by: Yihan Wang <yronglin777@gmail.com>
…213828) The action now checks out its own files so calling workflows don't need to do this. This helps prevent mistakes where the calling workflow does not checkout the right files causing this action to fail.
We need this to fix the test added in #212860. Right now it errors saying it can't find `ptxas`. We already have code doing this for the e2e tests, but we also need it for the unit tests. We had a similar fix for AMDGPU in #213149. Locally reproduced the issue and verified the fix. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…test cases (#213793) In future patches the coverage of the `__counted_by` family of attributes will be increased. To help with this, this patch refactors the existing test file. 1. Split `__sized_by` tests into their own file. In later patches files will be added for each attribute, so it makes sense for each attribute to have its own file. 2. Replace `testN` test case names with human-readable descriptions. Not all test cases that will be added in the future will apply to all attributes. If we kept using the `testN` naming convention it would leave odd gaps in the test numbering, because we try to keep what a test case tests consistent across files (i.e. `testN` would roughly test the same thing but with a different attribute). Using named test cases completely avoids this.
…#211371) A FORALL in a workshare construct could produce wrong results non-deterministically. This is caused by two issues in the workshare lowering: 1. A FORALL whose left-hand side may overlap its right-hand side is lowered into two loop nests around a runtime value stack: the first nest evaluates each right-hand side and pushes it, the second one fetches the saved values back with a running counter. That counter lives in a fir.alloca which, since omp.parallel is an alloca scope, is thread private. The counter is read, incremented and written back from inside the omp.single generated for the fetch, because the incremented value is only available there. Only the thread which executed the omp.single therefore bumped its own copy of the counter, and all the other threads kept a stale one and refetched an already consumed element on the following iterations. Collect the thread local memory which is only updated by the thread executing an omp.single and broadcast it with copyprivate, so that the copies of the other threads stay in sync. As nowait and copyprivate are mutually exclusive on a single construct, nowait is no longer set when there is something to broadcast. 2. nowait was only suppressed when the immediately enclosing operation was loop-like. A masked FORALL introduces a fir.if inside the fir.do_loop, so the last omp.single or omp.wsloop of the fir.if body was given nowait even though the loop may run it again, and even though there was more work after the loop. Thread the information down the recursion instead, so that only the work which is really last in the whole omp.workshare region may rely on the barrier emitted at the end of that region. Fixes #209942 Fixes #209943
…t access (#212741) Hovering over a vector swizzle expression (e.g. `.xyz`) or a matrix element access (e.g. `._m00`) previously produced no hover information, since ExtVectorElementExpr and MatrixElementExpr were not handled in getHoverContents(const Expr *E). This patch adds support for these expressions within `getHoverContents` by extracting the accessor name and resolved type for both node kinds. Fixes #212612
MBBSectionNumBlocks is accessed only via MapVector::operator[]. This patch changes its type to DenseMap to avoid populating the vector portion of MapVector.
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 : )