[DIArgList] Re-unique after changing operands to fix non-determinism #120
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
We have a large compile showing occasional non-deterministic behavior that is due to DIArgList not being properly uniqued in some cases. I tracked this down to handleChangedOperands, for which there is a custom implementation for DIArgList, that does not take care of re-uniquing after updating the DIArgList Args, unlike the default version of handleChangedOperands for MDNode. Since the Args in the DIArgList form the key for the store, this seems to be occasionally breaking the lookup in that DenseSet. Specifically, when invoking DIArgList::get() from replaceVariableLocationOp, very occasionally it returns a new DIArgList object, when one already exists having the same exact Args pointers. This in turn causes a subsequent call to Instruction::isIdenticalToWhenDefined on those two otherwise identical DIArgList objects during a later pass to return false, leading to different IR in those rare cases. I modified DIArgList::handleChangedOperands to perform similar re-uniquing as the MDNode version used by other metadata node types. This also necessitated a change to the context destructor, since in some cases we end up with DIArgList as distinct nodes: DIArgList is the only metadata node type to have a custom dropAllReferences, so we need to invoke that version on DIArgList in the DistinctMDNodes store to clean it up properly. Differential Revision: https://reviews.llvm.org/D108968 (cherry picked from commit badcd58)
vext01
pushed a commit
to vext01/llvm-project
that referenced
this pull request
Mar 21, 2024
Include the predicate in the ICmp lowering.
nikic
pushed a commit
to nikic/llvm-project
that referenced
this pull request
Dec 19, 2024
…-lang#120…464)" (llvm#120511) This reverts commit 2691b96. This reapply fixes the buildbot breakage of the original patch, by updating clang/test/CodeGen/ubsan-trap-debugloc.c to specify -fsanitize-merge (the default, which is merge, is applied by the driver but not clang_cc1). This reapply also expands clang/test/CodeGen/ubsan-trap-merge.c. ---- Original commit message: '-mllvm -ubsan-unique-traps' (llvm#65972) applies to all UBSan checks. This patch introduces -fsanitize-merge (defaults to on, maintaining the status quo behavior) and -fno-sanitize-merge (equivalent to '-mllvm -ubsan-unique-traps'), with the option to selectively applying non-merged handlers to a subset of UBSan checks (e.g., -fno-sanitize-merge=bool,enum). N.B. we do not use "trap" in the argument name since llvm#119302 has generalized -ubsan-unique-traps to work for non-trap modes (min-rt and regular rt). This patch does not remove the -ubsan-unique-traps flag; that will override -f(no-)sanitize-merge.
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.
We have a large compile showing occasional non-deterministic behavior
that is due to DIArgList not being properly uniqued in some cases. I
tracked this down to handleChangedOperands, for which there is a custom
implementation for DIArgList, that does not take care of re-uniquing
after updating the DIArgList Args, unlike the default version of
handleChangedOperands for MDNode.
Since the Args in the DIArgList form the key for the store, this seems
to be occasionally breaking the lookup in that DenseSet. Specifically,
when invoking DIArgList::get() from replaceVariableLocationOp, very
occasionally it returns a new DIArgList object, when one already exists
having the same exact Args pointers. This in turn causes a subsequent
call to Instruction::isIdenticalToWhenDefined on those two otherwise
identical DIArgList objects during a later pass to return false, leading
to different IR in those rare cases.
I modified DIArgList::handleChangedOperands to perform similar
re-uniquing as the MDNode version used by other metadata node types.
This also necessitated a change to the context destructor, since in some
cases we end up with DIArgList as distinct nodes: DIArgList is the only
metadata node type to have a custom dropAllReferences, so we need to
invoke that version on DIArgList in the DistinctMDNodes store to clean
it up properly.
Differential Revision: https://reviews.llvm.org/D108968
(cherry picked from commit badcd58)