- Notifications
You must be signed in to change notification settings - Fork 77
merge main into amd-staging #713
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
Conversation
This case did get documented upstream, in MicrosoftDocs/cpp-docs#4202, and the way that llvm-readobj prints it, implemented in that commit, is correct.
The encoded offset should be (OffsetInBytes/8)-1 due to an implicit offset of 1. Previously the operator ordering was inverted. As the offset is a multiple of 8, the incorrect operator ordering did produce the right result in all cases anyway.
Add support for vectorizing loops that select the index of the minimum or maximum element. The patch implements vectorizing those patterns by combining Min/Max and FindFirstIV reductions. It extends matching Min/Max reductions to allow in-loop users that are FindLastIV reductions. It records a flag indicating that the Min/Max reduction is used by another reduction. The extra user is then check as part of the new `handleMultiUseReductions` VPlan transformation. It processes any reduction that has other reduction users. The reduction using the min/max reduction currently must be a FindLastIV reduction, which needs adjusting to compute the correct result: 1. We need to find the last IV for which the condition based on the min/max reduction is true, 2. Compare the partial min/max reduction result to its final value and, 3. Select the lanes of the partial FindLastIV reductions which correspond to the lanes matching the min/max reduction result. Depends on llvm#140451 PR: llvm#141431
https://reviews.llvm.org/D52052 is to prevent register split on the MBB which have prolog instructions defining the exec register (or mask register that activate the threads of a warp in GPU). The constrain seems too strict, because 1) If the split is allowed, it may fit the free live range of a physical register, and no spill will happen; 2) The register class of register that is under splitting may not be the same to the register that is defined in prolog, so there is no interference with the register being defined in prolog. The current code has another small issue. The MBB->getFirstNonDebugInstr() just skip debug instructions, but SA->getFirstSplitPoint(Number) would skip label and phi instructions. This cause some MBB with label instruction being taken as prolog. This patch is to relax the split constrain on MMB with prolog by checking if the register defined in prolog has the common register class with the register being split. It allow the split if the register defined in prolog is physical register or there is no common register class. --------- Co-authored-by: Yuanke Luo <ykluo@birentech.com>
…ars (llvm#169215) `FormatStringConverter::appendFormatText` incorrectly treated non-ASCII characters (e.g. UTF-8) as negative values when using signed chars. This caused them to pass the `< 32` check for control characters. The negative values were passed to `llvm::hexdigit`, resulting in an OOB access and a crash. This closes [llvm#169198](llvm#169198)
searlmc1 left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| 3 single test reruns all failed: two suspect PRs |
…)" This reverts commit 9bae84b.
| !PSDB |
| suspected upstream PR failing hip bot : llvm#168259 |
No description provided.