[llvm] [Transforms][IPO] Add func suffix in ArgumentPromotion and DeadArgume… (PR #105742)

[via llvm-commits]

yonghong-song wrote:

> The general idea of changing the name seems reasonable; in these cases, we know the program doesn't actually depend on the name of the symbol, so the name is just for the sake of debugging.
> 
> Should we try to prevent accumulating more than one suffix on a function?

We probably should. Currently, I have seen suffix like .argprom.argprom, .argelim.argprom and specialized.1.argelim. 
.argprom.argprom is from llvm unit test. .argelim.argprom is from linux kernel O3 build.
.specialized.1.argelim is from linux kernel FULL LTO build.

Multiple suffix are totally possible here and could be longer in special cases. So it is indeed a good idea to shorten
the suffix. Maybe we could just one suffix and ignore the rest? For example, for '.argprom.argprom', we just use '.argprom'. For 'argelim.argprom', we just use '.argelim'? Form '.specialized.1.argelim', juse use '.specialized.1'?

> 
> If the name is using C++ mangling, does the demangler produce something reasonable? If not, can we modify the name in a demangler-friendly way?

I am not sure about this as my context is linux kernel which is C based. How do I know demangler produce something reasonable?

> 
> If you try to set a breakpoint on a function, how will a debugger react to the changed name?

Again, good question. But gcc already have functions like <func>.constprop.<n>, <func>.isra.<n>. Do gdb/lldb handle those functions?



https://github.com/llvm/llvm-project/pull/105742