Denormal floats handling

Dear @xianyi and everyone!

Is there a way to forbid denormals in the OpenBLAS?

I tried to execute the following code (MSVC2015) before calling any OpenBLAS routines:

	unsigned int current_word = 0;
	_controlfp_s(&current_word, _DN_FLUSH, _MCW_DN);
	_MM_SET_DENORMALS_ZERO_MODE(_MM_DENORMALS_ZERO_ON);
	_MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);

and it looked like it worked for some time (about a year)... Does it really affect OpenBLAS denormals handling (especially inside worker threads)?

I started to use some additional OpenBLAS functions and noticed that denormals started to reappear in results again and that extremely slows down computations. I'm heavily suspecting that it is the OpenBLAS, who is responsible for them. Probably, the worker threads might still have enabled denormals?...

How to get rid of them?

I'm using precompiled OpenBLAS-v0.2.19-Win64-int32.

Here is the complete list of used functions (if it helps):

• cblas_sgemm
• cblas_ssyrk
• cblas_ssymm
• LAPACKE_sgesvd

UPD: indeed, cblas_ssyrk() is a first function which produces the first denormalized float during execution... :-(

How to change denormals behaviour?

May be there is a (reachable from outside) way to execute custom code in context of OpenBLAS's worker threads if there's no predefined way to control denormals?

Start with cblas_ssyrk(), identified as the first function producing a denormalized float, and inspect how OpenBLAS worker threads are initialized. Reproduce the behavior with the listed CBLAS and LAPACKE calls on the precompiled Windows build, then determine whether denormal handling is preserved in worker threads. Done means the behavior is explained and a documented or tested way to control it is identified.