[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