[PATCH] D125418: [Arm64EC 6/?] Implement C/C++ mangling for Arm64EC function definitions.
Eli Friedman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Sep 21 12:35:51 PDT 2022
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
More information about the cfe-commits
mailing list