efriedma added a comment. > Sometimes we will emit the alias here but later the function will be inlined > or eliminated by DCE.
If the alias is externally visible, it can't be eliminated; the compiler can't tell whether the symbol is referenced. If the alias isn't externally visible, it's dead from the outset. Not sure how this could become an issue. > And later we need to emit alias for direct call thunk also, like > $originname$exitthunk. Direct call thunks aren't directly relevant here; we only emit them for declarations, not definitions. I guess this does imply that we need to teach arm64eccalllowering how to modify mangled symbol names... and we could use that same code to insert the $$h. > Put all of them into arm64eccalllowering pass should be better I think. I really don't want to do demangling in arm64eccalllowering. But looking at the generated patterns a bit more closely, maybe we don't have to fully parse the mangled symbol. If we can get away with just parsing the "?symbolname@@" at the beginning of the symbol, and ignore all the type-related stuff, I guess that would be okay. Alternatively, I guess we could use attributes to communicate the different mangled forms to the backend, but probably better to avoid that if we can. If we can solve the mangling issues, I guess generating the alias in arm64eccalllowering would be fine. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125418/new/ https://reviews.llvm.org/D125418 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
