turran 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 >
I added the most common patterns found in GLib in those two examples. At least with that, GLib properly works. I guess there might be other use cases, but I haven't found them yet. > > 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 (or LLVM features like ptr, for that > matter) are added or changed. I took a look again to `EMULATE_FUNCTION_POINTER_CASTS` and both examples work correctly. So something else is missing to be able to make GLib run properly. The examples are very narrow cases and don't expose the multi. c file problem, for example, but might be another thing Checking the generated wasm/wat, IIUC their approach, it wraps every indirect call with another call with a maximum number of arguments of type i64 for later pushing them into the stack and calling the real indirect call afterwards. The real indirect call will just pop the desired arguments, and everything will simply work. It is fixing the problem with a hammer IMHO, making all indirect calls slower when they are not really needed. I understand the benefit, but the cost is very high. https://github.com/llvm/llvm-project/pull/153168 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
