On 2/13/26 11:58, Arsen Arsenović wrote:
Hi Matthew,
Matthew Malcomson <[email protected]> writes:
Nice to know others see the benefit!
Having a common thread initialisation function sounds like a sensible idea.
One complication would be that (once I've investigated the three
improvements I mentioned above) I expect some of the thread
initialization done in the generic code would not be things that the
targets use (e.g. the `num_teams` member).
It seems to me that the particular example you mention is gated behind
(defined (LIBGOMP_USE_PTHREADS)), so indeed that'd need to be behind
such a preprocessor condition in the initialization function also.
I guess if that does turn out to be the case we could take a little
sub-optimality (in the parallel region so much less critical) rather
than making a generic function that is strongly tied to the current
implementation details of backends.
I must admit that I didn't compare thoroughly the generic and
platform-specific initialization code, so I am not sure how much of a
difference there is, but, in the worst-case scenario, it's not
unheard-of to place some steps behind #ifdef __AMDGCN__ and similar.
With sufficient commentary, that should still be maintainable, mostly
generic and optimal.
If those conditions don't nest much (and I hope they wouldn't), I think
it'd be alright to have a few such conditionals. Worst-case scenario,
it can be split up more so that the backend-specific parts are
implemented by the backend if it turns out to be a problem.
Sounds good to me.
Just to confirm you're thinking about this w.r.t. GCC 17 right (given
our point in the release cycle)?
Wanted to set expectations that I won't be picking it up until Stage 1
opens (just so you don't wonder what happened to the discussion).
