Very interesting, actually I started to do not set fast-math because of my switch to JUCE. Please see this screenshot from their project generator. The warning there is probably about non audio code?...
Reassociation in particular, that is, the ability to turn a*b*c*d into (a*b)*(c*d) or perhaps (a*c)*(b*d), is THE big thing when it comes to other optimizations, because it's often the thing that enables lumping constants together (so they can be constant folded), lumping loop-invariants together (so they can be moved out of the loop) ... and auto-vectorization (some of the more useful simple cases that you might actually expect from the compiler are things like parallel accumulation of FIR taps.. can't do that if reassociation is forbidden).
I've been compiling just about all my code with fast-math for ... idk ... 15-20 years now... and I'm not really sure if I can think of a single case where it'd caused issues with audio code. It has caused some head-scratching in some other cases (most notable swept 3D collision code; that one can suffer from both catastrophic precision loss if you reassociate wrong, and taking wrong branches if your comparisons are inconsistent), but so far I've yet to see a case where you can't make it work and generally I find that making code robust against fast-math tends to result in better code in general.
Got it....
Here the worst-case is where about 50% of the samples need to be clipped, because then the branch predictor is basically flipping coins trying to guess which way we go. If we instead do a conditional select (or a purpose built min/max instruction), then the branch predictor can happily unroll a dozen iterations of the loop into the ROB and the ROB gets to do it's job without having to be flushed all the time.
Statistics: Posted by liqih — Sat Sep 21, 2024 12:28 am