This is about Pd-E 0.42 / 0.43 on Intel
Although freeverb~.c has many calls to function fix_denorm_nan_float(), the object can't handle inf, NaN or subnormal numbers. If it gets an inf or NaN accidentally, the only way to recover from recycling NaN's is to reload the containing patch. If normal sound input is stopped, values in the delay lines gradually decay into the range of subnormal numbers, and CPU load increases dramatically.
Function fix_denorm_nan_float() doesn't really fix anything, it only returns the input value if it's good or zero if the input is bad. But the return value is nowhere stored. Probably, the function calls aren't even compiled at all for that reason, making [freeverb~] so efficient. SVN shows that the function was introduced in 2007, incorrectly replacing a type punning macro in the original freeverb~.c for Pd/MaxMsp.
All together, 40 such calls are intended per iteration of the perform loop, with 3 conditional checks each. If this would be really implemented, my estimation is that it would make [freeverb~] 1.5 or 2 times more expensive. It would be overkill. For all mentioned issues there are cheap and effective workarounds which can even be implemented in a Pd patch. Attached patch freeverb~-test.pd demonstrates bugs and workarounds. One day, [freeverb~] may be rewritten in this sense.