aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
diff options
context:
space:
mode:
authorYevgeny Rouban <yrouban@azul.com>2023-03-31 10:54:44 +0700
committerYevgeny Rouban <yrouban@azul.com>2023-03-31 11:44:05 +0700
commitc53d807321f680f81c0599e4395be480dec1ee3e (patch)
treec75b4f180d3362fb6046c50ad99e9decd167fcb6 /llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp
parent9eccc145aa957e56846f1587e543eb6310a404ae (diff)
downloadllvm-c53d807321f680f81c0599e4395be480dec1ee3e.zip
llvm-c53d807321f680f81c0599e4395be480dec1ee3e.tar.gz
llvm-c53d807321f680f81c0599e4395be480dec1ee3e.tar.bz2
[IR] Allow destruction of symbol table entries regardless of DiscardValueNames
Value::setNameImpl() is used both to set and reset name of the value. In destructor of Function all arguments get reset their names (see Function::clearArguments()). If the arguments had their names set (e.g. when the function was created with LLVMContex::DiscardValueNames == true) then their ValueName entries referred by the function's symbol table must be destructed. They are not destructed if LLVMContex::DiscardValueNames is set to false because of the fast path in Value::setNameImpl(). See the new test cases that demonstrate the problem. Without the fix they both crash in the function's destructor. In Value::setNameImpl() this patch narrows down the fast path return for DiscardValueNames == true to allow destruction of ValueName entries if any. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D143487
Diffstat (limited to 'llvm/lib/CodeGen/AssignmentTrackingAnalysis.cpp')
0 files changed, 0 insertions, 0 deletions