forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 4
[AutoBump] Merge with 465a3ce9 (Jan 09) (33) #503
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
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
Use combineMetadataForCSE instead of manually enumerating known metadata kinds. This is a typical sinking transform for which combineMetadataForCSE is safe to use (with DoesKMove=true). Part of llvm#121495.
…122065) After 0dedd6f and 03229e7, invalid concept declarations might lack expressions for evaluation and normalization. This could make it crash in certain scenarios, apart from the one of evaluation concepts showed in 03229e7, there's also an issue when checking specializations where the normalization also relies on a non-null expression. This patch prevents that by avoiding building up a type constraint in such situations, thereafter the template parameter wouldn't have a concept specialization of a null expression. With this patch, the assumption in ASTWriterDecl is no longer valid. Namely, HasConstraint and TypeConstraintInitialized must now represent different meanings for both source fidelity and semantic requirements. Fixes llvm#115004 Fixes llvm#121980
…ValueTracking. NFC. (llvm#122064) Needed by llvm#121958.
Fixes llvm#121965. --------- Co-authored-by: Christian Ulmann <christianulmann@gmail.com> Co-authored-by: Alex Zinenko <git@ozinenko.com>
…s after C++26 for bugprone-unused-local-non-trivial-variable (llvm#121783) Fixed: llvm#121731 According to https://eel.is/c++draft/basic.scope.scope#5, name independent declaration should not be warned as unused
…lvm#121968) Co-authored-by: Kiran Chandramohan <kiranchandramohan@gmail.com>
…122018) catering to platform differences as those calls are not posix.
substition -> substitution in-betweem -> in-between
…essor (llvm#120249) Part 2 (and final part) following llvm#120102 Allows users to do things like: ``` if (o->x.has_value()) { ((*o).x).value(); } ``` where the `->` and `*` are operator overload calls. A user could instead extract the nested optional into a local variable once instead of doing two accessor calls back to back, but currently they are unsure why the code is flagged.
Save the bitwidth value as a `ConstantExpr` with the value set. Remove the `ASTContext` parameter from `getBitWidthValue()`, so the latter simply returns the value from the `ConstantExpr` instead of constant-evaluating the bitwidth expression every time it is called.
These are triggering after b037bce.
This reverts commit 81fc3ad. This breaks some LLDB tests, e.g. SymbolFile/DWARF/x86/no_unique_address-with-bitfields.cpp: lldb: ../llvm-project/clang/lib/AST/Decl.cpp:4604: unsigned int clang::FieldDecl::getBitWidthValue() const: Assertion `isa<ConstantExpr>(getBitWidth())' failed.
The dependency file and the P1689 file are text files, but the open call misses the OF_Text flag. This PR adds the flag. Fixes regressions in test cases ClangScanDeps/modules-extern-unrelated.m and ClangScanDeps/P1689.cppm.
Need to check if the GEP bases are equal and return false early. Also, need to return false if the lookup is too deep, considering bases equal too. Fixes a crash in the assertion.
…e DAP object lifecycle. (llvm#120457)" This reverts commit 0d9cf26. Breaks the lldb-aarch64-windows buildbot.
This is in order to prepare for future MR where we will extend `ReachingDefAnalysis` to stack slots.
…"default<O3>" to allow DOS to correctly evaluate the RUN command Necessary for running update_test_checks.py on windows
The version string can be anything, don't restrict it to digits and dots. It's derived from the resource dir, so just check for that.
I think this is a false positive for a non-capturing lambda, but I can't find anything in the standard that guarantees that these have eternal lifetime.
…m#121366) This PR adds VALID_ELEMENT_ACCESS and VALID_INPUT_RANGE checks for vector<bool>.
Add baseline test for 64-bit adds when the low half of an operand is known 0.
…nsions are available (llvm#122082) This PR fixes llvm#122075. We prefer SPV_INTEL_optnone over SPV_EXT_optnone when both extensions are available, otherwise, when a target specifies a required extension explicitly rather than allowing any of those (e.g., by providing --spirv-ext=all command line argument), the Backend's behavior remains unchanged. An existing test case is updated to check the case of 2 alternative extensions available at the same time.
…121663) This is intended to help with flang `-ftime-report` support: - llvm#107270. With this change, I was able to cherry-pick llvm#107270, uncomment `llvm::TimePassesIsEnabled = true;` and compile with `-ftime-report`. I also noticed that `clang/lib/Driver/OffloadBundler.cpp` was statically constructing a `TimerGroup` and changed it to lazily construct via ManagedStatic.
/llvm-project/llvm/lib/Support/Timer.cpp:565:74:
error: extra ';' outside of a function is incompatible with C++98 [-Werror,-Wc++98-compat-extra-semi]
static bool mtg::TrackSpace() { return ManagedTimerGlobals->TrackSpace; };
^
1 error generated.
…19826) `RegisterClassInfo::getRegPressureSetLimit` is a wrapper of `TargetRegisterInfo::getRegPressureSetLimit` with some logics to adjust the limit by removing reserved registers. It seems that we shouldn't use `TargetRegisterInfo::getRegPressureSetLimit` directly, just like the comment "This limit must be adjusted dynamically for reserved registers" said. Separate from llvm#118787
When a destroying delete overload is selected, the destructor is not automatically called. Therefore, the destructor can be deleted without causing the program to be ill-formed. Fixes llvm#46818
This PR enables the use of the status register in inline assembly. This is necessary to, for example, set and retrieve the current interrupt mask. --------- Co-authored-by: kirk <knickish@gmail.com>
This patch adds a section for OpenMP 6.0 features. --------- Co-authored-by: Joseph Huber <huberjn@outlook.com>
We already custom lower the other 16-bit element type shuffles.
…1961) In DXC, setting the vulkan version automatically sets the target spir-v version to the maximum spir-v version that the vulkan version must support. So for Vulkan 1.2, we set the spir-v version to spirv 1.5 because every implementation of Vulkan 1.2 must support spirv 1.5, but not spir-v 1.6.
This change ensures that base relocations are sorted in the output, aligning with MSVC linker behavior. While input files typically provide sorted relocations, this update guarantees correct sorting even if the input relocations are unordered.
In my patch there, I left a test expectation stale. Tests with `REQUIRES: Z3` never run because no bots check such configurations. Here I'm adjusting the test expectations to meet reality.
Rework involves below: - Return unsigned value, the number of div/rem bits actually needed. - Change from AtLeast(SignBits) to MaxDivBits hint. - Use MaxDivBits hint for unsigned case. - Remove unnecessary second early exit. Mostly NFC changes.
Replaces llvm#121886 Fixes llvm#120254 (hopefully 🤞) ## Problem Consider the following example: ```fortran program test real :: x(1) integer :: i !$omp parallel do reduction(+:x) do i = 1,1 x = 1 end do !$omp end parallel do end program ``` The HLFIR+OMP IR for this example looks like this: ```mlir func.func @_QQmain() { ... omp.parallel { %5 = fir.embox %4#0(%3) : (!fir.ref<!fir.array<1xf32>>, !fir.shape<1>) -> !fir.box<!fir.array<1xf32>> %6 = fir.alloca !fir.box<!fir.array<1xf32>> ... omp.wsloop private(@_QFEi_private_ref_i32 %1#0 -> %arg0 : !fir.ref<i32>) reduction(byref @add_reduction_byref_box_1xf32 %6 -> %arg1 : !fir.ref<!fir.box<!fir.array<1xf32>>>) { omp.loop_nest (%arg2) : i32 = (%c1_i32) to (%c1_i32_0) inclusive step (%c1_i32_1) { ... omp.yield } } omp.terminator } return } ``` The problem addressed by this PR is related to: the `alloca` in the `omp.parallel` region + the related `reduction` clause on the `omp.wsloop` op. When we try translate the reduction from MLIR to LLVM, we have to choose an `alloca` insertion point. This happens in `convertOmpWsloop` where at entry to that function, this is what the LLVM module looks like: ```llvm define void @_QQmain() { %tid.addr = alloca i32, align 4 ... entry: %omp_global_thread_num = call i32 @__kmpc_global_thread_num(ptr @1) br label %omp.par.entry omp.par.entry: %tid.addr.local = alloca i32, align 4 ... br label %omp.par.region omp.par.region: br label %omp.par.region1 omp.par.region1: ... %5 = alloca { ptr, i64, i32, i8, i8, i8, i8, [1 x [3 x i64]] }, align 8 ``` Now, when we choose an `alloca` insertion point for the reduction, this is the chosen block `omp.par.entry` (without the changes in this PR). The problem is that the allocation needed for the reduction needs to reference the `%5` SSA value. This results in inserting allocations in `omp.par.entry` that reference allocations in a later block `omp.par.region1` which causes the `Instruction does not dominate all uses!` error. ## Possible solution - take 2: This PR contains a more localized solution than llvm#121886. It makes sure that on entry to `initReductionVars`, the IR builder is at a point where we can starting inserting initialization region; to make things cleaner, we still split the builder insertion point to a dedicated `omp.reduction.init`. This way we avoid splitting after the latest allocation block; which is what causing the issue.
Adds some comments and re-name variables to clarify the usage.
This reverts commit 45d4698. NVPTX fabs & fneg are incompatible with LLVM's semantics as LLVM guarantees the payload of NaNs to stay the same while PTX mangles NaNs. The bad patterns are still in the NVPTX backend and should probably be removed, since this change only exposed the bad behavior.
…types. (llvm#122240) When a vector is instantiated with a pointer type (`T` being `const Foo*`), the inferred annotation becomes `push_back(const Foo*& value [[clang::lifetime_capture_by(this)]])`. For reference parameters, the `lifetime_capture_by` attribute treats the lifetime as referring to the referenced object -- in this case, the **pointer** itself, not the pointee object. In the `push_back`, we copy the pointer's value, which does not establish a reference to the pointer. This behavior is safe and does not capture the pointer's lifetime. The annotation should not be inferred for cases where `T` is a pointer type, as the intended semantics do not align with the annotation. Fixes llvm#121391
The LLVM Discord bot now has the ability to scrape the LLVM calendar & send reminders about upcoming office hours events and sync-ups. Document that here. While I'm in the area, add a note about the bot's ability to @mention people when they're on buildbot blamelists. Related to llvm/Community.o#19
…llvm#121557) Adds an end-to-end test for `tensor.unpack` with dynamic inner tile sizes. While relatively simple (e.g., no vectorization), this example required a few fixes in handling `tensor.unpack` (and similar fixes for `tensor.pack` before that): * llvm#119379, llvm#121393, llvm#121400. The end goal for this test is to incrementally increase its complexity and to work towards scalable tile sizes. Note, this PR complements llvm#115698 in which similar test for `tensor.pack` was added.
One common error seen in CUDA/HIP compilation is: fatal error: 'cmath' file not found which is due to inproper installation of standard C++ libraries. Since it happens with #include_next, users may feel confusing which cmath is not found and how to fix it. Add an error directive to help users resolve this issue.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.