nikic wrote: I still don't think that using operand bundles for this is appropriate. If you take a look at all the other operand bundles (https://llvm.org/docs/LangRef.html#operand-bundles) they consistently have some kind of impact on the semantics of the call. Also keep in mind that the default implication of an operand bundle is that it can read and write arbitrary memory. This is not going to be super relevant in this context because indirect calls already have unknown effects, but would be relevant if devirtualization happens and the operand bundle is still attached.
If you properly design the metadata, I expect that preservation through optimization will be quite robust. There just aren't that many optimizations that act on indirect calls. The main one is merging of multiple call-sites via hoist/sink, and metadata can handle that. I'll also add that no matter what design you use, you still need to have some kind of graceful fallback for the case where the callee_type bundle/metadata is missing, e.g. because you're linking in an object from a frontend that doesn't support it. cc @efriedma-quic for a second opinion on what to do here. https://github.com/llvm/llvm-project/pull/87573 _______________________________________________ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
