This is an archive of the discontinued LLVM Phabricator instance.

[IR] Allow destruction of symbol table entries regardless of DiscardValueNames (Deeper Refactoring)
AbandonedPublic

Authored by yrouban on Feb 7 2023, 9:23 PM.

Details

Summary

This is a deeper refactoring of D143487 that tries avoiding Twine -> StringData conversion.

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 removes the fast path return for DiscardValueNames == true to allow destruction of ValueName entries.

Diff Detail

Event Timeline

yrouban updated this revision to Diff 496395.Feb 10 2023, 3:08 AM

removed file permission changes. kept 644.
please review.

efriedma added inline comments.Mar 21 2023, 1:25 PM
llvm/lib/IR/Value.cpp
324

Is there some reason to move the call to getSymTab() earlier?

334

Why do we want to check isTriviallyEmpty() here? Is this related to the earlier isTriviallyEmpty() check somehow?

344

Not sure why you're messing with this assertion. A void value doesn't have a name, and never had a name (unless you're doing something weird with mutating the types of values, which isn't relevant here).

359

I think the reason the way the code was structured this way is because of this "NOTE"... if you restructure this way, probably delete the NOTE.

yrouban abandoned this revision.Mar 30 2023, 9:49 PM

Abandoned this patch in favor of alternative D143487.