[PATCH] D143487: [IR] Allow destruction of symbol table entries regardless of DiscardValueNames

Yevgeny Rouban via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 20 22:15:16 PDT 2023


yrouban added a comment.

In D143487#4207263 <https://reviews.llvm.org/D143487#4207263>, @efriedma wrote:

> If I'm understanding correctly, the issue here is that you create a context with shouldDiscardValueNames() disabled, parse some code, then enable shouldDiscardValueNames()?  That's a little exotic, but I guess we can accommodate if there isn't a measurable penalty for normal frontends.

I believe you get it right. It is a functional issue and I do not expect any performance impact.

> As an alternative to this patch, I guess we could add a "clearValueName()" method that doesn't check shouldDiscardValueNames() at all, and use it in the necessary places.

To not complicate things further I would suggest trying the //clearValueName()// approach only if we see any performance impact.



================
Comment at: llvm/lib/IR/Value.cpp:320
-  if (getContext().shouldDiscardValueNames() && !isa<GlobalValue>(this))
-    return;
-
----------------
efriedma wrote:
> I would guess it's important that we preserve the fast-path here (although I don't have numbers).  Amending it to `getContext().shouldDiscardValueNames() && !isa<GlobalValue>(this) && !hasName())` or something like that is probably trivial enough that it doesn't really matter, but the current patch runs a lot of code that doesn't do anything.
I agree. //shouldDiscardValueNames// should be used only to check if we need the new name, but the old name (if any) we have to discard unconditionally.


================
Comment at: llvm/lib/IR/Value.cpp:323
   SmallString<256> NameData;
   StringRef NameRef = NewName.toStringRef(NameData);
   assert(NameRef.find_first_of(0) == StringRef::npos &&
----------------
efriedma wrote:
> Can we just make this `StringRef NameRef = NeedNewName ? NewName.toStringRef(NameData) : "";`,instead of messing with the rest of the function?
I agree that we have to avoid //NewName.toStringRef(NameData)//. I have another patch that refactors //Value::setNameImpl()// further in this way - D143550. Please take a look and choose one patch that I should finalize.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143487/new/

https://reviews.llvm.org/D143487



More information about the llvm-commits mailing list