On Thu, Jul 31, 2003 at 10:45:01 +0200, Alfons Adriaensen wrote: No, the thing I've been using is (from the music-dsp mailing list): #define FLUSH_TO_ZERO(fv) (((*(unsigned int*)&(fv))&0x7f800000)==0)?0.0f:(fv) but I'm beginning to suspect it doesn't always work. Sometimes you can just add low amplitude whitenoise instead. - Steve

Simon Jenkins wrote: Whoops... I spoke too soon. I've found a way to make the macro fail: /*==================================================== Program to demonstrate FLUSH_TO_ZERO macro failure. S.Jenkins 2003 Using GCC 2.95.4 Macro fails at optimisation -O1 or above if -fstrict-aliasing is also used. ====================================================*/ #include <stdio.h> #define FLUSH_TO_ZERO(fv) ((((*(unsigned int*)&(fv))&0x7f800000)==0)?0.0f:(fv)) float TestResult; int main (int argc, char **argv) { int j; /* set TestResult to a value that is just barely above the denormal float threshold */ *(unsigned int *)&TestResult = 0x00800001; /* now decay TestResult down into the denormals... */ for( j = 0; j <1024; j++ ) { TestResult = TestResult * 0.999f; /* ...but flush it to zero (causing all subsequent values to be zero) as soon as it actually becomes denormal */ TestResult = FLUSH_TO_ZERO(TestResult); } /* Result should be zero and - if we instrument the code - we should only see ourselves paying the penalty of a single denormal calculation */ printf( "TestResult: %e\n", TestResult ); exit(0); } /*=== the end ==========================================*/ When compiled with -01 -fstrict-aliasing, this produces a denormal result and takes a relatively long time doing so. I guess that the -fstrict-aliasing option is telling the optimiser to ignore the possibility that a pointer to unsigned int might actually point to a global float variable, so it believes the "unsigned int" that the macro is testing cannot be the same entity as the float that the loop is modifying. So it moves the test outside of the loop. Anyway, enough doom and gloom. Here's the fix: #define FLUSH_TO_ZERO(fv) ((((*(volatile unsigned int*)&(fv))&0x7f800000)==0)?0.0f:(fv)) (Note: This will stop working once Juhana gets the "volatile" keyword removed from the C language :) ) Simon Jenkins (Bristol, UK)

On Fri, Aug 01, 2003 at 11:36:22 +0100, Simon Jenkins wrote: Those are all good points, but my concerns are that I dont think it actually does what its supposed to do :) It could be the pointer aliasing + optimisation thing thugh, I'l check it out. - Steve

Simon Jenkins wrote: Unfortunately -ffloat-store slows code down a *lot*. More unfortunately, I can't prove that the macro will always function correctly without it. I still can't actually break it, but things I have read whilst searching the web have given me definite cause for concern that it could fail. I might mail a compiler list about this one. Here's where I've got to so far. Comments are welcome. (Note: This might, or might not, suffer from the same problems that FLUSH_TO_ZERO might or might not suffer from :)) /* === benormal.h - Copyright (C) 2003 Simon Jenkins === */ #define FLOAT_EXP_MASK (0x7F800000) #define FLOAT_AS_BITS(x) (*(volatile unsigned int *)&(x)) /*============================================================================ Function: FlushMultiplyQuick ============================================================================== Purpose: Returns the product of its parameters, but flushes the result to zero if there is suspicion (not proof!) that the result might have been a denormal float. Method: The result is flushed to zero if the magnitude of either parameter is below 2**-63. Comments: This never produces a denormal, but sometimes flushes a result that would not have been denormal. ============================================================================*/ static inline float FlushMultiplyQuick( float a, float b ) { return ( ( FLOAT_AS_BITS(a) & 0x60000000 ) && ( FLOAT_AS_BITS(b) & 0x60000000 ) ) ? (a * b) : 0.0f; } /*============================================================================ Function: FlushMultiplyQuickAsym ============================================================================== Purpose: Returns the product of its parameters, but flushes the result to zero if there is suspicion (not proof!) that the result might have been a denormal float. Method: The result is flushed to zero if the magnitude of the first parameter is below 2**-63. Comments: Faster than FlushMultiplyQuick, but might produce a denormal if the second parameter is non-zero with magnitude < 2**-63. Never produces a denormal if second parameter has magnitude >= 2**-63, ============================================================================*/ static inline float FlushMultiplyQuickAsym( float a, float b ) { return ( FLOAT_AS_BITS(a) & 0x60000000 ) ? (a * b) : 0.0f; } /*============================================================================ Function: FlushMultiply ============================================================================== Purpose: Returns the product of its parameters, but flushes the result to zero if there is suspicion (not proof!) that the result might have been a denormal float. Method: Computes a lower bound for the exponent of the result by adding the exponents of the parameters. Flushes the result if the lower bound suggests a possible denormal result. Comments: A bit slower than the other methods, but much less likely to flush a non-denormal result. (A non-denormal will only be flushed if the mantissas of the parameters would have "saved" an otherwise denormal result by having a product >= 2). Never produces a denormal result. ============================================================================*/ static inline float FlushMultiply( float a, float b ) { return ( ( FLOAT_AS_BITS(a) & FLOAT_EXP_MASK ) + ( FLOAT_AS_BITS(b) & FLOAT_EXP_MASK ) > 0x3F800000 ) ? (a * b) : 0.0f; } /*=== end of file ===*/ Simon Jenkins (Bristol, UK)

Steve Harris wrote: Its only an extra branch on the MULs where you actually use it. I'm not suggesting replacing every multiplication everywhere with this, but to pinpoint *exactly* the MUL that might first produce a denormal (*if* that is actually a potential problem in an app) and replacing just one crucial multiplication with a flushing function, which hopefully will propogate the zero through the rest of the calculation. They definitely fix actual problems, but I'm not at all convinced that they fix all problems. I suspect that its still broken. If so then my flushing multiply functions are possibly (but not definitely) broken in the same way. Simon Jenkins (Bristol, UK)

On Sat, Aug 02, 2003 at 11:14:25 +0300, Jussi Laako wrote: Yes, I think thats correct, but I got a performace penalty when I've tried telling gcc to produce SSE code instead of 387. I should play with it somemore, its possibel that you can tell the 387 to ignore the exceptions. - Steve

On Mon, Aug 04, 2003 at 07:35:42 +0300, Jussi Laako wrote: Thanks, and Hmmm.... If its possible to disable it (on a per process basis, we dont want to turn it off for every process), maybe it should be a recommendation for realtime LADSPA hosts? Its hard to imageine that any realtime audio app would require denormal support for anything. - Steve

Jussi Laako wrote: The trouble with turning off the exceptions is, erm, that they are already turned off. (Following discussion is intel 32-bit and equivalent specific:) There are two exceptions relevant to denormals: - A denormal operand exception occurs when an operand is denormal. - An underflow exception occurs when the result of an operation is denormal, You can either enable these exceptions and deal with them in software, or you can mask them and let the FPU deal with them. If you let the FPU deal with them (which is the default) then it proceeds with calculations that have denormal operands, and it produces denormal results when calculations underflow. There is no hardware option to flush either denormal operands or denormal results to zero. (I think that there is such an option on Itanium processors though, and on some other processor families). The slow-down that happens with denormal calculations isn't the result of exception handling, its the result of the FPU hardware itself taking a lot longer to perform the calculations. So, at least until the next hardware upgrade, we're stuck with detecting and dealing with denormals ourselves. Here are some possibly useful macros: typedef unsigned int fpu_status_t __attribute__ ((__mode__ (__HI__))); #define GET_FPU_STATUS_WORD(x) __asm__ ("fnstsw %0" : "=m" (*&x)) #define CLEAR_FPU_STATUS_BITS __asm__ ("fnclex") #define FPU_SW_DENORMAL_EXCEPTION_MASK (0x0002) #define FPU_SW_UNDERFLOW_EXCEPTION_MASK (0x0010) The exception bits are "sticky" so we can do things like... fpu_status_t FPUStatus; /*..*/ CLEAR_FPU_STATUS_BITS; /*..*/ /* do a chunk of FP math here */ /*..*/ GET_FPU_STATUS_WORD(FPUStatus); if( FPUStatus & ( FPU_SW_DENORMAL_EXCEPTION_MASK | FPU_SW_UNDERFLOW_EXCEPTION_MASK ) != 0 ) { /* either we were passed a denormal or we generated one ourselves */ /*..*/ /* flush results to zero or - depending what the math was - take some other appropriate action */ /*..*/ } Simon Jenkins (Bristol, UK)

On Wed, Aug 06, 2003 at 09:31:17 +0300, Jussi Laako wrote: That explains why I've been getting bug reports from P4 users, and cant reproduce it on my athlon, thanks. There were several serious bugs with gcc's sse2 code generation unfortunatly. I dont know when, or if they have been fixed. - Steve