forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 76
merge main into amd-staging #616
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
This helps cases where the immediate range of FDUP is not sufficient.
…is deduced (llvm#164440) Previously, the handling of the `cleanup` attribute had some checks based on the type, but we were deducing the type after handling the attribute. This PR fixes the way the are dealing with type checks for the `cleanup` attribute by delaying these checks after we are deducing the type. It is also fixed in a way that the solution can be adapted for other attributes that does some type based checks. This is the list of C/C++ attributes that are doing type based checks and will need to be fixed in additional PRs: - CUDAShared - MutualExclusions - PassObjectSize - InitPriority - Sentinel - AcquireCapability - RequiresCapability - LocksExcluded - AcquireHandle NB: Some attributes could have been missed in my shallow search. Fixes llvm#129631
…68405) This tells the build system to check and regenerate the *GenRegisterInfo*.inc files, should any of them be missing for whatever reason. A follow-up from <llvm#167700>.
…sure amt doesn't depend on original load chain (llvm#168400) Relax fix for llvm#165755 / llvm#165850 - it doesn't matter if the amt is dependent on the original load value, just any users of the chain
- Detect cases where LHS & RHS values will not cause overflow (when the Hi halfs are zero).
This pass aims to narrow i64 types on TOSA operations to i32. It can be useful for legalizations from various frameworks. It comes with the following options: - "aggressive-rewrite" - This option is typically able to narrow more values, but may impact numerical behaviour if not used carefully. - "convert-function-boundaries" - If enabled, parameters/ results to/from a function may be narrowed. Otherwise, casts are inserted to preserve the I/O of the function. Currently the non aggressive mode is very limited, targeting an argmax -> cast sequence that has been observed during legalization as well as some data layout operations that can always narrow. Support for more operations will be added in the future. Co-authored-by: Vitalii Shutov <[email protected]> Co-authored-by: Shubham <[email protected]> Co-authored-by: Declan Flavin <[email protected]> Signed-off-by: Luke Hutton <[email protected]> Co-authored-by: Vitalii Shutov <[email protected]> Co-authored-by: Shubham <[email protected]> Co-authored-by: Declan Flavin <[email protected]>
This patch fixes the only RTSan test that was broken by enabling lit's internal shell on Darwin. This patch rewrites the test to prefix env variables with `env` and to avoid the use of subshells.
…d() (llvm#164392) Use the implementation in libomptarget. If libomptarget is not available, always return the UID / device number of the host / the initial device.
…lvm#167519) [andv, eorv, orv, s/uaddv, s/umaxv, s/uminv] sve_reduce_##(none, ?) -> op's neutral value sve_reduce_##(any, neutral) -> op's neutral value [andv, orv, s/umaxv, s/uminv] sve_reduce_##(all, splat(X)) -> X [eorv] sve_reduce_##(all, splat(X)) -> 0
Currently, there are no diagnostics issued when including a deprecated header, since the diagnostic is issued inside a system header. This patch fixes that by using `#warning` instead, which also simplifies the implementation of the deprecation warnings.
…_from_uid()" (llvm#168547) Reverts llvm#164392 due to fortran issues
…168450) Update VPlan to populate VPIRFlags during VPInstruction construction and use it when creating widened recipes, instead of constructing VPIRFlags from the underlying IR instruction each time. The VPRecipeWithIRFlags constructor taking an underlying instruction and setting the flags based on it has been removed. This centralizes initial VPIRFlags creation and ensures flags are consistently available throughout VPlan transformations and makes sure we don't accidentally re-add flags from the underlying instruction that already got dropped during transformations. Follow-up to llvm#167253, which did the same for VPIRMetadata. Should be NFC w.r.t. to the generated IR. PR: llvm#168450
Note that getCurrentUnwindRow does not change any state. Identified with unused-local-non-trivial-variable.
Identified with modernize-loop-convert.
While I am at it, this patch switches to the constructor that takes a container instead of a pair of begin/end. Identified with readability-const-return-type.
- MemoryEffectsAttr in MLIR LLVM dialect is out of sync with LLVM itself.
Fixes: e1979ae ("Implement gd to ie relaxation for aarch64.")
This patch makes all tsan tests work with the internal shell on Darwin. Tests were using various features not supported by the internal shell, mainly subshells and not using env to set environment variables. This patch also fixes one of the dynamiclib substitutions to not use a subshell. Reviewers: ndrewh, DanBlackwell, fmayer, vitalybuka Reviewed By: DanBlackwell Pull Request: llvm#168544
llvm#162443) In some cases, such as when recommending the compiler option _FORTIFY_SOURCE, the current custom message format is clunky. Now, when the reason starts with `>`, the replacement string is omitted., so only the Reason is shown. `^function$,,has a custom message;` - function 'function' has a custom message; it should not be used `^function$,,>has a custom message and no replacement suggestion;` - function 'function' has a custom message and no replacement suggestion --------- Co-authored-by: Donát Nagy <[email protected]>
…llvm#168542) Where possible: * notifyMatchFailure happen first * then op.emitOpError * finally assertions / op creation. --------- Co-authored-by: Jakub Kuderski <[email protected]>
Closes llvm#99097 Closes llvm#99100 As ddx and ddy are near identical implementations I've combined them in this PR. This aims to unblock llvm#161378 --------- Co-authored-by: Alexander Johnston <[email protected]>
…d-bundler and AMD SPIR-V. (llvm#168521) `clang-linker-wrapper` was incorrectly calling `clang-offload-bundler` for AMD SPIR-V. This resulted in a binary that couldn't be executed if built using the new driver. The runtime couldn't recognise the triple triggering this error at execution time: ``` No compatible code objects found for: gfx90a:sramecc+:xnack-, ``` With this PR, this is solved: ``` Creating ISA for: gfx90a:sramecc+:xnack- from spirv ```
This is a simple translation of the current WORKSPACE file. * External repos are replaced with `bazel_dep()`. The versions have been bumped to newer versions. * `maybe()` doesn't seem to be a thing, so I just removed that. * Existing repos where we define our own BUILD file in third_party_build have *not* been replaced due to compatibility issues. For example, `nanobind_bazel` could replace the `nanobind` config we have, but switching to that caused some build errors. * For these existing repos, they have been specified as module extensions This should have no effect since `.bazelrc` defines `common --enable_bzlmod=false --enable_workspace` Tested locally: `bazel test --enable_bzlmod --noenable_workspace --config=generic_clang @llvm-project//... //...`
I missed these attributes when I added the wrapper for GPUFuncOp in fbdd98f.
This patch makes Clang produce the crash reproducer shell script for IR inputs as well.
…he shadow map (llvm#167772) The AddressSanitizer transform currently defaults to placing the shadow map in address space 0, but it is desirable for some targets (namely BPF) to select a different address space for the map. Add a compilation option for specifying the address space of the target.
…PF target (llvm#167768) The AddressSanitizer transform does not have a default offset registered for the shadow map. Set the default shadow map offset for BPF be dynamically set by the KASAN implementation.
The BPF LLVM target currently doesn't support turning on the AddressSanitizer pass, either for userspace ASAN or KASAN. Enable the KASAN option for the BPF target in anticipation of a KASAN implementation for BPF.
Collaborator
Author
ronlieb
approved these changes
Nov 18, 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.