Andrew Stubbs <[email protected]> writes:

> On 05/05/2026 14:14, Arsen Arsenović wrote:
>> +  /* TODO(arsen): This should be part of a mechanism that allows us to 
>> override
>> +     nthreads-var with OMP_NUM_THREADS.  But, we currently don't have 
>> access to
>> +     that list on the device.
>> +
>> +     thr->task->icv.nthreads_var = ...;  */
>
> The previous code did write to this field. Why does the new thread not do at
> least the same? (This does not seem like "no functional changes".)

This write was redundant with gomp_init_task, which does:

  /* task = thr->task, prev_icv = &start_data->prev_icvs */
  gomp_init_task (struct gomp_task *task, struct gomp_task *parent_task,
                  struct gomp_task_icv *prev_icv)
    /* [...] */
    task->icv = *prev_icv;

The generic team.c implementation does (abridged):

  nthreads_var = icv->nthreads_var;
  if (__builtin_expect (gomp_nthreads_var_list != NULL, 0)
      && thr->ts.level < gomp_nthreads_var_list_len)
    nthreads_var = gomp_nthreads_var_list[thr->ts.level];
  gomp_init_task (thr->task, task, icv);
  thr->task->taskgroup = taskgroup;
  team->implicit_task[0].icv.nthreads_var = nthreads_var;

... i.e. it allows replacing the value of nthreads_var with an element
of gomp_nthreads_var_list, before writing it back.

On the device, however, that list is always empty, and analogous logic
was not even present, so the value of nthreads_var is necessarily the
same as prev_icv->nthreads_var, being written into a field where
prev_icv->nthreads_var was already copied.

So, it never had an effect.
-- 
Arsen Arsenović

Reply via email to