dschuff wrote: I still have concerns about what exactly the semantics of this change is, and it's a problem that it's not really documented, there are only 2 tests
> Here `fp` needs to be traced back to `fp_less` which I doubt the > FuncCastEmulation will handle. In a real-life case, they belong to two > different modules, being sfp and the call to sfp.fp in GLib, for example, and > the casted function in GStreamer. The definition of sfp.fp is a pointer (int) > without type information, at least on the IR generated. If the logic has to > be done on the call (sfp.fp) and not the cast on sfp's field, I don't know > how it is going to be done properly with FuncCastEmulation. FuncCastEmulation doesn't actually operate on casts, it actually operates only at callsites. Function pointers always have their usual values no matter how they are generated, casted, or passed around; the transformation only happens at call time. This is why it works across modules despite being so simple. I just want to reiterate again how much simpler a solution that operates at the callsite is compared to trying to trace the origin of all the pointers and casts. Currently there are only 2 tests, but there would need to be a lot more to cover the various ways function pointers can be materialized and casted, including ones that have nothing to do with the GLib use case, because we need to make sure we can adequately describe the behavior of the language change. (This is another simplicity advantage of solutions that work on the wasm level; the language is simpler, so the transformation is simpler and easier to understand, describe, and test, and there's less risk of issues when e.g. new frontend or C++ features are added or changed). https://github.com/llvm/llvm-project/pull/153168 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
