[PATCH] D105733: [OpaquePtr] Require matching signature in getCalledFunction()

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D105733#2872361 <https://reviews.llvm.org/D105733#2872361>, @dexonsmith wrote:

> @nikic, I think we're mostly on the same page about the current state; I agree with your point that a new name could be safer; IMO the existing name is the right one for the documented behaviour (the 500+ callers carve out a desire path <https://en.wikipedia.org/wiki/Desire_path>), but there are ways to stage changes like that to minimize risk.
>
> Regardless of how things are staged / named / etc., any thoughts on the right thing to do? IOW, it seems to me like the proposed audit would reduce differences between `--force-opaque-pointers` on vs. off; do you agree? enough of a reduction that it's worth doing the audit?

"Call to bitcasted function" is considered non-canonical in LLVM IR and InstCombine will try to move casts from the call to the arguments (see transformConstExprCastCall). I believe it should succeed for any cases where opaque pointers will make the signatures the same. Thanks to this, most passes will only see the canonicalized form that performs a direct call. For that reason, I wouldn't expect this to have a major impact during the opaque pointer switch, at least relative to other changes (much less bitcasts, more i8 GEPs, etc.)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105733/new/

https://reviews.llvm.org/D105733