Back in 2013 I wrote a blog post entitled "DSP Tech Brief : Some Notes On Implementing DSP Algorithms - C or Assembly, Fixed or Floating Point" : http://blog.numerix-dsp.com/2013/06/some-notes-on-implementing-dsp.html.
Since I wrote that first post I've often thought about writing an update to discuss denormalized floating point numbers. I never got around to it but I recently saw a post that explains the issue perfectly.
Before I get to the specific blog post, a bit of DSP history might help.
Back in the very earliest days of floating point DSPs the silicon manufacturers had the choice of supporting IEEE floating point numbers or not. Supporting IEEE standard floating point numbers sounds like the logical choice however the silicon required to support denormalized numbers without increasing processing time for floating point operations (like general purpose CPUs do) meant that the cost (i.e. number of transistors) of supporting IEEE floating point numbers was far higher than not supporting the standard. Understanding denormalized numbers was key to writing code that could be portable between DSPs that supported them and those that didn't.
Now-a-days most DSPs support IEEE floating point numbers with no run-time overhead for handling denormalized numbers however when the same code is run on a general purpose CPU then the issue of denormalized number support needs to be taken very seriously, to avoid the code becoming very slow.
Now to the excellent summary of the issue of denormalized floating point numbers by Nigel Redmon at EarLevel Engineering :
The main aricle is : https://www.earlevel.com/main/2019/04/19/floating-point-denormals/
And there are some additional useful caveats here : https://www.earlevel.com/main/2019/04/19/floating-point-caveats/
The best part about Nigel's main article is that it gives some great suggestions about how to avoid these problems.