Optimize gemv for small M, large N only if it can be done in a threadsafe manner

[martin-frbg]

commit 8e5a108 tried to improve the performance of #532 but introduced a static array in the process, breaking programs like numpy that call into OpenBLAS from several concurrent threads. Supersedes the simple revert from #1852 with the intention to fix #1844 without sacrificing performance where possible.

[brada4]

Looks like includes the observations from mentioned issue.

[martin-frbg]

Sorry, I did not get the comment ? (Unfortunately I cannot test this on my hexacore system this weekend, but I had tested the general idea outlined in the comments on #1852 earlier)

[brada4]

It looks that it enables gemv optimisation for OMP only.
Does not fail with Android UserLAnd (sort of debian chroot, atom CPU) in OMP or pthread builds, though I cannot tell if it ever failed before in this combination.
EDIT: it fails in pre=patches pthread version and ubuntu numpy, though multiprocessorness of this "debian" is not always guaranteed, you somehow need to spin many bg apps to make cpus wake from park. Does not seem possible from "app" I'd wait for more reliable tests...

[martin-frbg]

The intention is that it enables the optimization only when the static buffer can be made thread safe, that is either under OMP or when the compiler is capable of assigning C11-like TLS.

[brada4]

Patches do the trick most likely just that android tablet chroot is not always multiprocessor like a normal computer....

[martin-frbg]

Merged after successful local tests

[mattip]

Thanks. Since this is a critical bug for NumPy, will it be part of a bugfix release?

[martin-frbg]

Guess 0.3.4 is overdue in any case, will see if I can do it next weekend or at least by the end of this month. Need to try to get a decent handle on the equally ugly #1851 as well.