dschuff wrote: > Hello @dschuff. Thanks for your comments. > > > Or another random idea (for the "semi-transparently call with signature > > mismatches" problem, not the "fix the bugs in my code" problem): What if we > > represented function pointers (in the source) as being in a different > > address space, using the existing `address_space(N)` clang/LLVM attributes? > > They could be freely casted, written into memory and have the same integer > > values as they otherwise would, but when you call through them, we could > > either use a generic catch-all thunk like Binaryen's `fpcast-emu` pass does > > today, or perhaps something more fancy, like a LUT check and a > > more-specific conversion thunk. That could be feasible if e.g. the > > `FunctionPointer` C type and `FUNCTION_POINTER` macro could be suitably > > redefined. Then we maybe wouldn't need any changes to the code at callsites. > > I'm not aware of what `address_space` does, but I understand it is something > that would require a change in the original source code, which I think the > approach should be transparent to the programmer. > > About the LUT, isn't it similar to the approach commented on [#153168 > (review)](https://github.com/llvm/llvm-project/pull/153168#pullrequestreview-3122024433) > and replied on [#153168 > (comment)](https://github.com/llvm/llvm-project/pull/153168#issuecomment-3212203688) > ?
Let me refine what I meant here a little bit. The key problem I have with your proposed approach is that it redefines the semantics of the language in a subtle and hard-to-understand way (i.e. compile-time vs runtime casts, as mentioned [above](https://github.com/llvm/llvm-project/pull/153168#pullrequestreview-3122024433)). I think that this isn't going to be very "transparent to the programmer" if you have a flag that just changes this behavior across the program, it could have effects outside of the very-specially-designated intended uses. I agree with the statement above that changing the indirect call behavior is better than changing the casting behavior because it's much easier to understand and more predictable. It's also why I'm wondering if we can localize the effect to specific callsites which can mitigate both any increased cost for the calls, and any potentially-surprising behavior changes. The example you've given have centralized macros such as `FUNCTION_POINTER` and typedefs for the various types involved. If we can, for example, define the macro such that the calls can call a compiler builtin to make the dispatch call, then we could localize any extra runtime costs. Or, if we could use the typedef to designate the pointer types in a special way, we could do something similar (this is what I was speculating about with the addrspace thing). It's true that this isn't completely transparent in that it would require no source changes at all, but I think it's pretty reasonable, and I would hope that the GLib code is organized in such a way that only the special signal dispatch code needs this behavior, and it might therefore be acceptable to take some macro changes. https://github.com/llvm/llvm-project/pull/153168 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
