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.
Details
- Reviewers
efriedma
Diff Detail
Event Timeline
change mangle param from CallBase to FunctionType+AttributeList to support entrythunk also.
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.