merge main into amd-staging #741
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
Close llvm#170235 The cause of the issue is it didn't check friendness for decls in ordinary namespace if it isn't visible. It is fine for code before modules, since everything is visible. But it is not true after modules came in. This patch adjusts this. Note that this doesn't change the control flow for non-modules codes, as the decls in ordinary namespace is always visible then it won't never fall in following friendness check.
It looks like the providers don't get loaded on arm32 bots: llvm#170412 Skipping for now since I don't have access to a machine to investigate it. Signed-off-by: Med Ismail Bennani <[email protected]>
Not updating cxx_dr_status.html yet, because CWG2917 test might need major adjustments before make_cxx_dr_status can be ran.
According to the spec: > A vector register cannot be used to provide source operands with more > than one EEW for a single instruction. A mask register source is > considered to have EEW=1 for this constraint. There must be a mask `V0` in `vmerge` variants so the sources should use register classes without `V0`. This fixes llvm#169905. Co-authored-by: Luke Lau <[email protected]>
Signed-off-by: Med Ismail Bennani <[email protected]>
This patch adds a check in validation for delinearization to ensure that the offset calculation does not overflow. If it overflows, different array accesses (e.g., `A[0][0]` and `A[1][0]`) could map to the same linear index, leading to incorrect behavior. For fixed-size arrays, the check is relatively straightforward. However, for dynamic-size arrays (i.e., arrays where the size is not known at compile time), it's difficult to prove this statically, and it going to fail for almost all cases. Maybe we need to add some runtime checks or reasoning based on `inbounds` like LAA does. Fixes the test cases added in llvm#169048.
…#168650) - Following llvm#168029. This is a step toward a unified interface for masked/gather-scatter/strided/expand-compress cost modeling. - Replace the ad-hoc parameter list with a single attributes object. API change: ``` - InstructionCost getGatherScatterOpCost(Opcode, DataTy, Ptr, VariableMask, - Alignment, CostKind, Inst); + InstructionCost getGatherScatterOpCost(MemIntrinsicCostAttributes, + CostKind); ``` Notes: - NFCI intended: callers populate MemIntrinsicCostAttributes with same information as before.
…_TAG_typedef (llvm#170135) Depends on: * llvm#170132 Clang gained the `-gtemplate-alias` not too long ago, which emits C++ alias templates as `DW_TAG_template_alias` (instead of `DW_TAG_typedef`). The main difference is that `DW_TAG_template_alias` has `DW_TAG_template_XXX` children. The flag was not enabled by default because consumers (mainly LLDB) didn't know how to handle it. This patch adds rudimentary support for debugging with `DW_TAG_template_alias`. This patch simply creates the same kind of `TypedefDecl` as we do for `DW_TAG_typedef`. The more complete solution would be to create a `TypeAliasTemplateDecl` and associated `TypeAliasDecl`. But that would require DWARF to carry generic template information, but currently each `DW_TAG_template_alias` represents a concrete instantiation. We could probably hack up some working AST representation that includes the template parameters, but I currently don't see a compelling reason to. All we need is the `DW_AT_name` and the `DW_AT_type` that the typedef refers to. rdar://137499401
llvm#169007) Currently, the getOrInsertDeclaration API requires callers to explicitly provide overload types for overloaded intrinsics, placing a significant burden on callers who must determine whether overload types are needed. This typically results in conditional logic at each call site to check if the intrinsic is overloaded and manually match the intrinsic signature. This patch introduces a new getOrInsertDeclaration overload that automatically deduces overload types from the provided return type and argument types, then uses this API to simplify IRBuilder::CreateIntrinsic. The new API uses Intrinsic::matchIntrinsicSignature internally to resolve overloaded types, eliminating the need for callers to do manual overload detection.
Collaborator
Author
ronlieb
approved these changes
Dec 3, 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.