[AutoBump] Merge with c57b9f5a (Sep 21) (9) #423
Merged
Conversation
This file contains 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
Additional tests for llvm#89958, following discussion at llvm#92177.
...and "[lldb/Interpreter] Introduce `ScriptedStopHook{,Python}Interface` & make use of it (llvm#105449)"
This reverts commit 76b827b, and commit 1e131dd
because the first commit caused the test command-stop-hook-output.test to fail.
This makes unit tests compatible with the assertion added in llvm#106524, by setting the isSigned flag to the correct value or changing how the value is constructed.
Add initial transform to move out loop-invariant recipes. This also helps to fix a divergence between legacy and VPlan-based cost model due to legacy using ScalarEvolution::isLoopInvariant in some cases. Fixes llvm#107501. PR: llvm#107894
…llvm#108699) This PR fixes a bug in `verifyAffineMinMaxOp` that allowed `map` of `affine.max` and `affine.min` to have an empty result. Fixes llvm#108368.
…nt generic `__builtin_elementwise_min/max` intrinsics (llvm#109259) Noticed while working on llvm#109160
… the equivalent generic `__builtin_elementwise_add_sat` intrinsics (llvm#109269) Noticed while working on llvm#109160 I've left out the sub_sat intrinsics for now - not sure about the history behind them using Intrinsic::wasm_sub_sat_* instead of Intrinsic::*sub_sat
…lvm#109174) Change AsmMatcherEmitter to use const RecordKeeper. This is a part of effort to have better const correctness in TableGen backends: https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
…llvm#109177) Change DisassemblerEmitter to use const RecordKeeper. This is a part of effort to have better const correctness in TableGen backends: https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
llvm#109187) Change GISelCombinerEmitter to use const RecordKeeper. This is a part of effort to have better const correctness in TableGen backends: https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
…#109365) Use const Record pointers in PredicateExpander. This is a part of effort to have better const correctness in TableGen backends: https://discourse.llvm.org/t/psa-planned-changes-to-tablegen-getallderiveddefinitions-api-potential-downstream-breakages/81089
Adopt `indent` for indentation DAGISelMatcher and DecoderEmitter.
…vm#102975)" This reverts commit b3533a1. It caused test failures in shared library builds: https://lab.llvm.org/buildbot/#/builders/80/builds/3854
This fixes:
```
[1832/3777] Building CXX object
lib\SandboxIR\CMakeFiles\LLVMSandboxIR.dir\SandboxIR.cpp.obj
In file included from
C:\src\git\llvm-project\llvm\lib\SandboxIR\SandboxIR.cpp:9:
C:\src\git\llvm-project\llvm\include\llvm/SandboxIR/SandboxIR.h(4400,16):
warning: unqualified friend declaration referring to type outside of the
nearest enclosing namespace is a Microsoft extension; add a nested name
specifier [-Wmicrosoft-unqualified-friend]
4400 | friend class TargetExtType; // For LLVMCtx.
| ^
| ::llvm::
1 warning generated.
```
This reverts commit 3b3accb.
… as text (llvm#107906)" This reverts commit edf3b27.
We already infer this in IPSCCP (which runs very early, so cannot benefit from inlining and simplifications) and SCCP (which runs without PredicateInfo, so does not use assumes). Do it in CVP as well, so it can handle cases that IPSCCP/SCCP can't. Fixes llvm#98946 (everything apart from f2, where the assume is dropped by the frontend).
…#109274) This fixes a crash when svdiv's third parameter is svdup_s64(1)
…2608) This is an almost-final step in eliminating debug-intrinsics -- read more about that here: https://llvm.org/docs/RemoveDIsDebugInfo.html . To correctly update variable location information in the background when inserting instructions, we need some information carried at runtime in BasicBlock::iterator, hence deprecating pointer-insertion. An immediate fix for any deprecation warnings is to call "getIterator" on the insertion position pointer. If you intend on inserting at the start of a block, use BB->begin() or similar methods to fetch the appropriate iterator.
…SET_BITS (llvm#108057) From llvm#107988 We were not intercepting the 64 bit versions of these calls, leading to tests failing when _FILE_OFFSET_BITS = 64.
…onversions for boolean vectors (llvm#108657) Fixes llvm#108326
This will affect only Bazel configuration for now.
As discussed in [the RFC](https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608) we need a way to create labels in the assembler-generated line section in order to support the future addition of the [DW_AT_LLVM_stmt_sequence](https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434) attribute. We have a similar precedent for such behavior with the [.cfi_label](llvm#97922) instruction - so we add the `.loc_label THE_LABEL_NAME` instruction which: - Terminates the current line sequence in the line section - Creates a new label with the specified label name in the `.debug_line` section
) Since the migration from `@llvm.dbg.value` intrinsic to `#dbg_value` records, there is no way to retrieve the debug records for an `Instruction` in LLVM-C API. Previously, with debug info intrinsics, retrieving debug info for an `Instruction` could be done with `LLVMGetNextInstructions`, because the intrinsic call was also an instruction. However, to be able to retrieve debug info with the current LLVM, where debug records are used, the `getDbgRecordRange()` iterator needs to be exposed. Add new functions for DbgRecord sequence traversal: LLVMGetFirstDbgRecord LLVMGetLastDbgRecord LLVMGetNextDbgRecord LLVMGetPreviousDbgRecord See llvm/docs/RemoveDIsDebugInfo.md and release notes.
…ng spaces. (llvm#109421) The current logic assumes that check names do not have leading spaces. In cases like "-*, clang-diagnostic*", when processing the second check " clang-diagnostics-*" (with a leading space), the check fails on `CDPrefix.starts_with(Check)`, resulting in all diagnostics remaining disabled.
…e use of it (llvm#109498) This patch re-lands llvm#105449 and fixes the various test failures. --------- Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
…FC) (llvm#106774) (based on a conversation I had with @labath yesterday in llvm#106442) Most APIs that currently vend a Status would be better served by returning llvm::Expected<> instead. If possibles APIs should be refactored to avoid Status. The only legitimate long-term uses of Status are objects that need to store an error for a long time (which should be questioned as a design decision, too). This patch makes the transition to llvm::Error easier by making the places that cannot switch to llvm::Error explicit: They are marked with a call to Status::clone(). Every other API can and should be refactored to use llvm::Expected. In the end Status should only be used in very few places. Whenever an unchecked Error is dropped by Status it logs this to the verbose API channel. Implementation notes: This patch introduces two new kinds of error_category as well as new llvm::Error types. Here is the mapping of lldb::ErrorType to llvm::Errors: ``` (eErrorTypeInvalid) eErrorTypeGeneric llvm::StringError eErrorTypePOSIX llvm::ECError eErrorTypeMachKernel MachKernelError eErrorTypeExpression llvm::ErrorList<ExpressionError> eErrorTypeWin32 Win32Error ``` Relanding with built-in cloning support for llvm::ECError, and support for initializing a Windows error with a NO_ERROR error code.
…m#109500) In preparation for providing more information to rtsan's diagnostics output (via `__rtsan_expect_not_realtime`), this PR separates out all logic for i) making rtsan's assertions about real-time context state and ii) displaying diagnostics to the user - disentangling them both from the rtsan `Context`. We'll follow up this PR with a simplification to the unit tests that reflect this new separation.
…09347) - **[Inliner] Add tests for incorrect propagation of return attrs; NFC** - **[Inliner] Fix bug where attributes are propagated incorrectly** The bug stems from the fact that we assume the new (inlined) callsite is calling the same function as the original (callee) callsite. While this is typically the case, since `VMap` simplifies the new instructions, callee intrinsics callsites can end up not corresponding with the same function. This can lead to buggy propagation.
This builds the DAG from an ArrayRef of Instructions.
…Error (NFC) (llvm#106774)" This reverts commit b44da24.
This member function is supposed to be private to MC. Also add an ifunc test.
Disentangles (and simplifies) integration-like tests for `__rtsan::ExpectNotRealtime` and `__rtsan::Context` into simpler unit tests. None of the tests are new, but their assertions have changed to reflect the more direct testing strategy.
Follow-up to d620ba0.
…lvm#67802) This is useful with projects that put their (doxygen) comments at the implementation site, rather than the header.
https://reviews.llvm.org/D148728 introduced `bool Sequential` to unify `execute` and the old `spawn` without argument. However, sequential tasks might be executed by any worker thread (non-deterministic), leading to non-determinism output for ld.lld -z nocombreloc (see https://reviews.llvm.org/D133003). In addition, the extra member variables have overhead. This sequential task has only been used for lld parallel relocation scanning. This patch restores the behavior before https://reviews.llvm.org/D148728 . Fix llvm#105958 Pull Request: llvm#109084
…lvm#109465) Expose conversion patterns so they can be reused outside of this pass.
They aren't allowed here either.
Co-authored-by: Tarık Çelik <tarik.celik.0000@protonmail.com>
mgehre-amd
approved these changes
Dec 16, 2024
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.