Is `core::fmt::float` poorly optimized on thumbv7em-none-eabihf or is the binary analysis tooling incorrect?

Adding formatting output (write) for float numbers for Cortex M4F increase binary size twice: from 39396 bytes to 66468 bytes. (optimisation flag: z)
The main high weigh functions are (provided by cargo bloat):

2.4%  22.7% 11.2KiB             std core::fmt::float::float_to_decimal_common_shortest
1.9%  17.8%  8.8KiB             std core::fmt::float::float_to_decimal_common_exact
0.9%   8.6%  4.2KiB             std core::num::dec2flt::<impl core::str::traits::FromStr for f32>::from_str
0.4%   3.8%  1.9KiB             std core::fmt::Formatter::pad

and others

For desktop application (Apple M2Pro chip, native build) with same functions size lower than few kilobytes:

 0.1%   0.3%     732B         std core::fmt::float::float_to_decimal_common_exact
 0.1%   0.3%     624B         std core::fmt::float::float_to_decimal_common_shortest
  0.3%   0.6%   1.3KiB         std core::num::dec2flt::<impl core::str::traits::FromStr for f32>::from_str
 0.2%   0.4%     980B         std core::fmt::Formatter::pad

Which reason of overweigh these functions for Cortex-M4F?

Start by reproducing the reported size difference for thumbv7em-none-eabihf with optimization level z, comparing cargo bloat output for the Cortex-M4F and desktop builds. Investigate the listed core::fmt::float and core::num::dec2flt functions, then determine whether the excess size is generated code or an analysis-tooling issue and document the cause.