Minor notes regarding OpenMP implementation details

[nmnobre]

Hi @martin-frbg,

Two questions really (illustrated by the suggested changes):

1. Did we write USE_OPENMP_UNUSED on purpose? It seems odd that we'd call openblas_num_threads_env() on all cases, even when using OpenMP.
2. When we fixed nested-parallelism in Prevent accidental increase of the thread count inside a parallel region #5949, we just fixed the no. of threads to one, but I wonder if we should just recover the old behaviour?

Cheers,
-Nuno

[martin-frbg]

Hmm, the USE_OPENMP_UNUSED looks very much like a "lets' disable this conditional and see if it's really needed", I'll need to look up context. And defaulting to just a single thread when detecting to be in a parallel region is definitely the
"original" OpenBLAS behaviour

[nmnobre]

Hmm, the USE_OPENMP_UNUSED looks very much like a "lets' disable this conditional and see if it's really needed", I'll need to look up context.

It could well be, but it's in a ifndef, so its contents are always enabled (as opposed to always disabled).

And defaulting to just a single thread when detecting to be in a parallel region is definitely the "original" OpenBLAS behaviour

Okay, we can drop that commit. Or both, if it turns out the preprocessor condition is as intended. :)

[nmnobre]

Oh, and the following should probably be rewritten to explicitly state OMP_NUM_THREADS also does in fact affect pthreads builds?

OpenBLAS/docs/runtime_variables.md

Lines 5 to 6 in 6956dbc

	* `OMP_NUM_THREADS`: the number of threads to use (for OpenMP builds - note
	that setting this may also affect any other OpenMP code)