dschuff wrote: OK, sorry for the delay in looking at this. I do have some general thoughts. I think this is worth working on; yes, it's a really annoying problem that real-world code takes advantage of laxness in existing calling conventions in so many cases, but it is what it is; that's why WebAssemblyFixFunctionBitcasts exists in the first place. But I do share @efriedma-quic's concerns, especially about:
1. Standards compliance outside of the particular bad uses, i.e. round-tripping pointers (This can be mitigated by putting the solution behind a flag, but that just emphasizes the importance of # 2) 2. Developer comprehensibility/transparency on what the solution actually does (i.e. big +1 to the concern [above](https://github.com/llvm/llvm-project/pull/153168#pullrequestreview-3122024433). I also think it's worth exploring the design space a little more, to see if we can come up with something that could be more broadly applicable and comprehensible that still has acceptable cost. One thing we haven't discussed yet, is whether it would be acceptable to have some kind of explicit operation (either a cast or something associated with an indirect call), perhaps in the form of builtin/intrinsic. Obviously it would require a source change, but if the use sites are constrained enough then it might work. Then we could limit the costs to only be paid when needed, and make the effect much more comprehensible. https://github.com/llvm/llvm-project/pull/153168 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
