[msan] Add avx512-intrinsics.ll and avx512-intrinsics-upgrade.ll test case #123980
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 is forked from llvm/test/CodeGen/X86/avx512-intrinsics-upgrade.ll. It tests intrinsics that LLVM "auto-upgrades"; for example, @llvm.x86.avx512.mask.store is converted into @llvm.masked.store (which has the interesting side effect that MemorySanitizer can already handle it via its existing handleMaskedStore).
You can test this locally with the following command:git diff -U0 --pickaxe-regex -S '([^a-zA-Z0-9#_-]undef[^a-zA-Z0-9_-]|UndefValue::get)' 44f316811016e677ca3e6c6237619e71bae28986 af72ee8c34b11c58afe6e98bcc27090b11cd3257 llvm/test/Instrumentation/MemorySanitizer/X86/avx512-intrinsics-upgrade.ll llvm/test/Instrumentation/MemorySanitizer/X86/avx512-intrinsics.llThe following files introduce new uses of undef:
Undef is now deprecated and should only be used in the rare cases where no replacement is possible. For example, a load of uninitialized memory yields In tests, avoid using For example, this is considered a bad practice: define void @fn() {
...
br i1 undef, ...
}Please use the following instead: define void @fn(i1 %cond) {
...
br i1 %cond, ...
}Please refer to the Undefined Behavior Manual for more information. |
thurstond
changed the title
vitalybuka
requested changes
Jan 26, 2025
Fixed. Thanks for catching those! |
vitalybuka
approved these changes
Jan 27, 2025
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/65/builds/11275 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/50/builds/9433 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/154/builds/10901 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/190/builds/13521 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/13/builds/4938 Here is the relevant piece of the build log for the reference |
thurstond
added a commit
to thurstond/llvm-project
that referenced
this pull request
Jan 27, 2025
I had added the test in llvm#123980 and contemporaneously added AVX masked store/load intrinsics (llvm#123857) and forgot to update the test output for the intersection. This patch fixes the output.
thurstond
added a commit
that referenced
this pull request
Jan 27, 2025
thurstond
added a commit
that referenced
this pull request
Jan 27, 2025
….ll test case (#123980)" This reverts commit 980e86f. Reason: buildbot breakage (https://lab.llvm.org/buildbot/#/builders/154/builds/10901/steps/5/logs/FAIL__LLVM__avx512-intrinsics-upgrade_ll)
github-actions bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jan 27, 2025
I had added the test in llvm/llvm-project#123980 and contemporaneously added AVX masked store/load intrinsics (llvm/llvm-project#123857) and forgot to update the test output for the intersection. This patch fixes the output.
thurstond
added a commit
to thurstond/llvm-project
that referenced
this pull request
Jan 27, 2025
…e.ll test case (llvm#123980)" This reverts commit b2647ff i.e., relands llvm@980e86f. I had reverted it because of buildbot failures (e.g., https://lab.llvm.org/buildbot/#/builders/13/builds/4938/steps/5/logs/FAIL__LLVM__avx512-intrinsics-upgrade_ll), which I misdiagnosed. The likely root cause is that the target datalayout had not been specified; this reland adds that.
thurstond
added a commit
to thurstond/llvm-project
that referenced
this pull request
Jan 27, 2025
…e.ll test case (llvm#123980)" This reverts commit b2647ff i.e., relands llvm@980e86f. I had reverted it because of buildbot failures (e.g., https://lab.llvm.org/buildbot/#/builders/13/builds/4938/steps/5/logs/FAIL__LLVM__avx512-intrinsics-upgrade_ll), which I misdiagnosed. The likely root cause is that the target datalayout had not been specified; this reland adds that.
github-actions bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jan 28, 2025
…rinsics (#123857)" This reverts commit b9d301c i.e., relands db79fb2. I had mistakenly thought this caused a buildbot breakage (the actual culprit was my other patch, llvm/llvm-project#123980, which landed at the same time) and thus had reverted it even though AFAIK it is not broken.
thurstond
added a commit
that referenced
this pull request
Jan 28, 2025
…e.ll test case (#123980)" (#124500) This reverts commit b2647ff i.e., relands 980e86f. I had reverted the original patch because of buildbot failures (e.g., https://lab.llvm.org/buildbot/#/builders/13/builds/4938/steps/5/logs/FAIL__LLVM__avx512-intrinsics-upgrade_ll). This reland addresses the likely root cause; namely, that the target datalayout had not been specified. Additionally, this reland improves the test case by replacing undef with extra parameters.
thurstond
added a commit
that referenced
this pull request
Jan 29, 2025
The AVX/SSE variants are already handled heuristically (maybeHandleSimpleNomemIntrinsic via handleUnknownIntrinsic), but the AVX512 variants contain an additional parameter (the rounding method) which fails to match heuristically. This patch generalizes maybeHandleSimpleNomemIntrinsic to allow additional flags (ignored by MSan) and explicitly call it to handle AVX512 min/max ps/pd intrinsics. It also updates the test added in #123980
github-actions bot
pushed a commit
to arm/arm-toolchain
that referenced
this pull request
Jan 29, 2025
…124421) The AVX/SSE variants are already handled heuristically (maybeHandleSimpleNomemIntrinsic via handleUnknownIntrinsic), but the AVX512 variants contain an additional parameter (the rounding method) which fails to match heuristically. This patch generalizes maybeHandleSimpleNomemIntrinsic to allow additional flags (ignored by MSan) and explicitly call it to handle AVX512 min/max ps/pd intrinsics. It also updates the test added in llvm/llvm-project#123980
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.
These are forked from the corresponding files in llvm/test/CodeGen/X86/.
avx512-intrinsics.ll shows that many intrinsics are already heuristically handled by MSan, and can be used to track refinements to the intrinsic handling.
avx512-intrinsics-upgrade.ll tests intrinsics that LLVM "auto-upgrades"; for example, @llvm.x86.avx512.mask.store is converted into @llvm.masked.store (which has the interesting side effect that MemorySanitizer can already handle it via its existing handleMaskedStore).