Thanks a lot, Zebediah, for your comments on my vcomp patches; I really appreciate you taking time to review them!
Does it even make sense to make these unions? Can we just make the relevant members 64-bit?
Alternatively, should these be stored separately from the 32-bit versions? Tests showing what happens if you mix and match 32-bit and 64-bit calls might be helpful.
Right, I considered three alternatives: 1. Create new separate vcomp_thread and vcomp_task structures for the 64-bit data, 2. Increase the 32-bit data members to 64-bit, or 3. Use unions
Creating new separate 64-bit data structures for the 64-bit calls would necessitate adding a bunch of new and redundant code (to initialize the new structs, etc.), but would be the most performant. Increasing the 32-bit members to 64-bit would waste the most memory and be the least performant for 32-bit calls, but would eliminate redundant code. My choice of unions is a compromise; new data structures are unnecessary and the separate 32-bit and 64-bit calls each access their native data types, which is good for performance.
Using unions in this way is a traditional approach in OpenMP runtime implementations. For example, if you look at the code for libgomp, the most widely used OpenMP implementation, you will see that it uses unions to handle 32/64-bit variants in a similar manner:
https://github.com/gcc-mirror/gcc/blob/1931cbad498e625b1e24452dcfffe02539b12...
Could we share any (or all) of this code with the 32-bit version?
Yes, if the top priority was to minimize redundant code, then refactoring these functions to handle both the 32-bit and 64-bit cases is possible. However, performance would suffer. If you look at the other previously-implemented vcomp functions, you'll see that earlier Wine contributors implemented separate 32-bit and 64-bit versions of functions for other scheduling modes: _vcomp_for_static_init() and _vcomp_for_static_init_i8(), _vcomp_for_static_simple_init() and _vcomp_for_static_simple_init_i8(), etc. My patches follow this same pre-established pattern.
I believe that my patches strike a good balance between performance, memory usage, and code concision. clarity, and consistency. If you insist on me changing something, I'm happy to do so. Otherwise, I hope we can get these patches committed swiftly, so that I can move my attention to making further improvements to Wine's vcomp/OpenMP support.