[all-commits] [llvm/llvm-project] 0f915e: [RegAllocFast] Fix nondeterminism in debuginfo gen...

Teresa Johnson via All-commits all-commits at lists.llvm.org
Fri Jan 7 11:27:08 PST 2022

  Branch: refs/heads/release/13.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 0f915e755eae63df568e62b877dee558b97bbdc2
  Author: Ilya Yanok <ilya.yanok at gmail.com>
  Date:   2022-01-07 (Fri, 07 Jan 2022)

  Changed paths:
    M llvm/lib/CodeGen/RegAllocFast.cpp

  Log Message:
  [RegAllocFast] Fix nondeterminism in debuginfo generation

Changes from commit 1db137b1859692ae33228c530d4df9f2431b2151
added iteration over hash map that can result in non-deterministic
order. Fix that by using a SmallMapVector to preserve the order.

Differential Revision: https://reviews.llvm.org/D113468

(cherry picked from commit 3c47c5ca13b8a502de3272e8105548715947b7a8)

  Commit: 35df3f98639eedee2cc61f95add40a2b08276f44
  Author: Teresa Johnson <tejohnson at google.com>
  Date:   2022-01-07 (Fri, 07 Jan 2022)

  Changed paths:
    M llvm/include/llvm/IR/Metadata.h
    M llvm/lib/IR/DebugInfoMetadata.cpp
    M llvm/lib/IR/LLVMContextImpl.cpp

  Log Message:
  [DIArgList] Re-unique after changing operands to fix non-determinism

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 badcd585897253e94b7b2d4e6f9f430a2020d642)

Compare: https://github.com/llvm/llvm-project/compare/33f7aa65f5d7...35df3f98639e

More information about the All-commits mailing list