forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 75
merge main into amd-staging #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
z1-cciauto
merged 62 commits into
amd-staging
from
amd/merge/upstream_merge_20251105150714
Nov 6, 2025
Merged
merge main into amd-staging #503
z1-cciauto
merged 62 commits into
amd-staging
from
amd/merge/upstream_merge_20251105150714
Nov 6, 2025
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
Update tests to contain auto generated checks.
PR llvm#165993 accidentally broke the lowering of the `test.wait` Op. This patch fixes the issue and adds tests to verify the lowering to intrinsics for all mbarrier Ops, ensuring similar regressions are caught in the future. Additionally, the `cp-async-mbarrier` test is moved to the `mbarriers.mlir` test file to keep all related tests together. Signed-off-by: Durgadoss R <[email protected]>
llvm#166536) …e size is unknown Keep _negative suffix only for test cases when the size is negative
… checks (llvm#148810) This PR adds support for the NOTIFY specifier in the image selector as described in the 2023 standard, and add checks for the NOTIFY_TYPE type.
…ional (llvm#166032) This picks up from llvm#166028, making the `Function` argument optional: most cases don't need to provide it, but in e.g. InstCombine's case, where the instruction (select, branch) is not attached to a function yet, the function needs to be passed explicitly. Co-authored-by: Florian Hahn <[email protected]>
…lvm#166078) In the following example, `Functor::method()` inappropriately triggers a diagnostic that `outer()` is blocking by allocating memory. ``` void outer() [[clang::nonblocking]] { struct Functor { int* ptr; void method() { ptr = new int; } }; } ``` --------- Co-authored-by: Doug Wyatt <[email protected]>
…m#155630) When there's a deep inheritance hierarchy of multiple C++ classes (see below), then the mangled name of a VFTable can include multiple key nodes in the target name. For example, in the following code, MSVC will generate mangled names for the VFTables that have up to three key classes in the context. <details><summary>Code</summary> ```cpp class Base1 { virtual void a() {}; }; class Base2 { virtual void b() {} }; class Ind1 : public Base1 {}; class Ind2 : public Base1 {}; class A : public Ind1, public Ind2 {}; class Ind3 : public A {}; class Ind4 : public A {}; class B : public Ind3, public Ind4 {}; class Ind5 : public B {}; class Ind6 : public B {}; class C : public Ind5, public Ind6 {}; int main() { auto i = new C; } ``` </details> This will include `??_7C@@6BInd1@@ind4@@ind5@@@` (and every other combination). Microsoft's undname will demangle this to "const C::\`vftable'{for \`Ind1's \`Ind4's \`Ind5'}". Previously, LLVM would demangle this to "const C::\`vftable'{for \`Ind1'}". With this PR, the output of LLVM's undname will be identical to Microsoft's version. This changes `SpecialTableSymbolNode::TargetName` to a node array which contains each key from the name. Unlike namespaces, these keys are not in reverse order - they are in the same order as in the mangled name.
This patch fixes: polly/lib/Transform/ScheduleOptimizer.cpp:935:17: error: unused variable 'File' [-Werror,-Wunused-variable] polly/lib/Transform/ScheduleOptimizer.cpp:936:9: error: unused variable 'Line' [-Werror,-Wunused-variable] polly/lib/Transform/ScheduleOptimizer.cpp:937:17: error: unused variable 'Msg' [-Werror,-Wunused-variable]
Reviewers: Pull Request: llvm#166587
…166505) This patch aligns llvm::to_address with C++20 std::to_address by adding a static_assert to prevent instantiation with function types. The C++20 standard says that std::to_address is ill-formed on a function type.
These two functions are decalred in Hexagon.h. Identified with readability-redundant-declaration.
In C++17, static constexpr members are implicitly inline, so they no longer require an out-of-line definition. Identified with readability-redundant-declaration.
…_fadd_v2f16 (llvm#166547) We didn't remove the `t` for this builtin in the past due to not being sure if we should use `float16/half`. This patch doesn't fix the _Float16/half question, I'll address that in a separate patch later (after discussing the options on our weekly meeting). At the moment we maintain the `h` for this builtin (which is likely not what we want for HIP).
…llvm#166373) Since 022e782 (2017) this attribute has an effect on both aarch64 and x86_64; update the docs to reflect this.
…66350) This patch refactors the logic to define each component of the `math_errhandling` macro. It assumes that math error handling is supported by the target and the C library unless otherwise disabled in the preprocessor logic. In addition to the refactoring, the support for error handling via exceptions is explicitly disabled for Arm targets with no FPU, that is, where `__ARM_FP` is not defined. This is because LLVM libc does not provide a floating-point environment for Arm no-FP configurations (or at least one with support for FP exceptions).
…m#166527) This avoids unintentional comparisons between `SourceLanguage` and `LanguageType`. Also marks `operator bool` explicit so we don't implicitly convert to bool.
…lvm#164987) Introduce a new class for the TargetLowering usage. This tracks the subtarget specific lowering decisions for which libcall to use. RuntimeLibcallsInfo is a module level property, which may have multiple implementations of a particular libcall available. This attempts to be a minimum boilerplate patch to introduce the new concept. In the future we should have a tablegen way of selecting which implementations should be used for a subtarget. Currently we do have some conflicting implementations added, it just happens to work out that the default cases to prefer is alphabetically first (plus some of these still are using manual overrides in TargetLowering constructors).
…mpl (llvm#166585) This is unused and will not make sense.
Implement `xvrlw`.
…db to re-use it (llvm#165323) lldb's CPlusPlusNameParser is currently identifying keywords using it's own map implemented using clang/Basic/TokenKinds.def. However, it does not respect the language options so identifiers can incorrectly determined to be keywords when using languages in which they are not keywords. Rather than implement the logic to enable/disable keywords in both projects it makes sense for lldb to use clang's implementation. See llvm#164284 for more information
The VM_MEMORY_SANITIZER constant was added in macOs 10.15 and friends. Support using the constant on older OSes. Fixes llvm#156144
…e. (llvm#166225) Functions like isalpha / tolower can operate on chars internally. This allows us to get rid of unnecessary casts and open a way to creating wchar_t overloads with the same names (e.g. for isalpha), that would simplify templated code for conversion functions (see 315dfe5). Add the int->char converstion to public entrypoints implementation instead. We also need to introduce bounds check on the input argument values - these functions' behavior is unspecified if the argument is neither EOF nor fits in "unsigned char" range, but the tests we've had verified that they always return false for small negative values. To preserve this behavior, cover it explicitly.
…6234) This is a counterpart of llvm#166225 but for wctype_utils (which are not yet widely used). For now, I'm just changing the types from wint_t to wchar_t to match the regular ctype_utils change. The next change may rename most of the functions to match the name of ctype_utils variants, so that we could be calling them from the templated code operating on "const char*" and "const wchar_t*" strings, and the right function signature would be picked up.
Use `IfDefEmitter` and `NamespaceEmitter` in SDNodeInfoEmitter.
Users may have multiple devices and would like to resolve the homepath based on the machine they are on. expands the tilde `~` character at the front of the given file path.
This patch defines errno unit and integration test asserts as noop on GPU targets. Checking for errnos is tests has caused build breakages in previous patches.
…166471) If the input to LowerBufferFatPointers is such that the resource- and offset-specific `select` instructions generated for a `select` on `ptr addrspae(7)` fold away, the pass would crash when trying to replace an instruction with itself. This commit resolves the issue. Fixes iree-org/iree#22551
…llvm#154237) targets This patch enables support of the NV (non-volatile) bit in FLAT instructions in GFX9 (pre-GFX90A) targets.
The brace wrapping for Java records should now behave similar to classes. Before, opening braces for Java records were always placed in the same line as the record definition.
…lvm#166583) This information will be needed in more emitters, so start factoring it to be more reusable.
…6391) `R_AARCH64_ADD_ABS_LO12_NC` is for the `ADD` instruction in the `ADRP+ADD` sequence. For `ADRP+LDR` sequence generated in LDR relaxation, relocation type for `LDR` should be `R_AARCH64_LDST64_ABS_LO12_NC` if it is 64-bit integer load or `R_AARCH64_LDST32_ABS_LO12_NC` if 32-bit. Sorry should have included this in llvm#165787.
llvm#165956) Continued from llvm#165804 This maintains the BFI of the default branch. Originally `10/63`, post-pass, it ends up being `5/63 + 58/63 * 5/58`(first term is from `PROF`, second is the probability of going to the switch lookup times the probability, there, of taking the default branch) Issue llvm#147390
Cost of interleaved store of 8 factor and 16 factor are cheaper in AArch64 with additional interleave instructions.
…oned/unversioned selector (llvm#164507) We don't have sufficient information to know when the versioned (or unversioned) loop variant will be taken, so we mark the branch as having "unknown" probabilities. Issue llvm#147390
Enumeration of relocation types is not always sequential, e.g. on AArch64 the first real relocation type is 0x101. As such, the existing code in `Relocation::print()` was crashing while printing AArch64 relocations. Fix it by using `llvm::object::getELFRelocationTypeName()`.
Add additional tests for narrowing interleave groups with casts.
Collaborator
dpalermo
approved these changes
Nov 5, 2025
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.