This is an archive of the discontinued LLVM Phabricator instance.

[ARM64EC 13/?] Mangle thunk for arm64ec
Needs ReviewPublic

Authored by bcl5980 on Aug 30 2022, 9:41 AM.

Details

Reviewers
efriedma
Summary

Try to mangle thunk based on function type to match MSVC.
For now it only help debug and it still can't eliminate the same thunks with the same type.
Later we can canonicalize thunk type to match the mangle name then don't create thunk for the same type.

Diff Detail

Event Timeline

bcl5980 created this revision.Aug 30 2022, 9:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 30 2022, 9:41 AM
bcl5980 requested review of this revision.Aug 30 2022, 9:41 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 30 2022, 9:41 AM
bcl5980 updated this revision to Diff 456861.Aug 30 2022, 10:18 PM

update to match latest MSVC

bcl5980 updated this revision to Diff 457522.Sep 2 2022, 1:01 AM

add float type array mangle

bcl5980 updated this revision to Diff 457525.Sep 2 2022, 1:11 AM
bcl5980 updated this revision to Diff 458084.Sep 5 2022, 8:12 PM

change mangle param from CallBase to FunctionType+AttributeList to support entrythunk also.

bcl5980 updated this revision to Diff 458085.Sep 5 2022, 8:21 PM

add i128 mangle

Instead of using a separate routine to compute the name, it might make sense to integrate the computation of the name into the actual computation of the signature of the call. If you write something complicated like this twice, it's hard to ensure the two copies are precisely consistent.

Instead of using a separate routine to compute the name, it might make sense to integrate the computation of the name into the actual computation of the signature of the call. If you write something complicated like this twice, it's hard to ensure the two copies are precisely consistent.

I'm sorry but can you help to explain the integrate the computation of the name into the actual computation of the signature of the call ? I haven't write twice so I don't know where the question is.

Basically, with this patch, the code walks the thunk signature twice: once to figure out the mangling, and once to figure out the LLVM IR signature of the called function. The two walks care about the same properties of the arguments, so ideally we could tie them together. (So, for example, the first function is an integer. That means we mangle it as "i8", use the LLVM IR type "i64", and pass it directly.) I'm concerned the two walks could fall out of sync, and we could end up with edge cases where the mangler doesn't interpret the signature the same way as the code emitting the actual code in the thunk.

Basically, with this patch, the code walks the thunk signature twice: once to figure out the mangling, and once to figure out the LLVM IR signature of the called function. The two walks care about the same properties of the arguments, so ideally we could tie them together. (So, for example, the first function is an integer. That means we mangle it as "i8", use the LLVM IR type "i64", and pass it directly.) I'm concerned the two walks could fall out of sync, and we could end up with edge cases where the mangler doesn't interpret the signature the same way as the code emitting the actual code in the thunk.

Ah, you are right. Thanks for the explanation. I will refine the code later.

bcl5980 updated this revision to Diff 462798.Sep 25 2022, 8:40 PM

Generate mangle and IR signature in one function to avoid mismatch.