tree 0a3d3e5d9f23e7a7becf7a03d3311abe78435662
parent e048e97f5280e8a232a43ae134d395aeab67c2e8
author Teresa Johnson <tejohnson@google.com> 1630379221 -0700
committer Nikita Popov <nikita.ppv@googlemail.com> 1637081226 +0100

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