core: add unstable no_fp_fmt_parse to disable float formatting code

[nbdd0121]

In some projects (e.g. kernel), floating point is forbidden. They can disable
hardware floating point support and use +soft-float to avoid fp instructions
from being generated, but as libcore contains the formatting code for f32
and f64, some fp intrinsics are depended. One could define stubs for these
intrinsics that just panic 1, but it means that if any formatting functions
are accidentally used, mistake can only be caught during the runtime rather
than during compile-time or link-time, and they consume a lot of space without
LTO.

This patch provides an unstable cfg no_fp_fmt_parse to disable these.
A panicking stub is still provided for the Debug implementation (unfortunately)
because there are some SIMD types that use #[derive(Debug)].

[rust-highfive]

r? @scottmcm

(rust-highfive has picked a reviewer for you, use r? to override)

[scottmcm]

I think this is bigger than my lib-impl hat's purview, so I've nominated it for libs team discussion.

[nbdd0121]

I am also preparing a patch that adds a no_i128 cfg to remove some i128 parsing code. Maybe the discussion can include that as well?

The goal is not to remove the type f32/f64/i128/u128 completely; we just want to build a libcore without depending on any intrinsics that needs to be implemented as function calls.

[nagisa]

Consider using Cargo's feature infrastructure for the implementation of this. Furthermore, features should ideally be additive (i.e. in this case you'd add an enabled-by-default floating-point feature rather than a no-floating-point one).

(as another nit: since these don't remove the types, but just the formatting code, perhaps this should be reflected in the name?)

[nbdd0121]

Consider using Cargo's feature infrastructure for the implementation of this. Furthermore, features should ideally be additive (i.e. in this case you'd add an enabled-by-default floating-point feature rather than a no-floating-point one).

I followed a previous PR that adds a cfg to remove OOM handling code, see #84266 (comment). It seems that libs team is not comfortable with enable-by-default features.

(as another nit: since these don't remove the types, but just the formatting code, perhaps this should be reflected in the name?)

Well, this removes both parsing and formatting code. What would be a better name, no_floating_point_parse_and_fmt? Or maybe into two flags?

[nagisa]

Two cfgs do definitely seem to make naming these easier: --cfg no_fp_fmt and --cfg no_fp_parse with whatever in place of fp: flt, float, floating_point….

[Amanieu]

I don't understand why this is needed: if you don't use f32/f64 in your code then the linker will see that the float formatting code is unreachable and will not link it in.

[nbdd0121]

I don't understand why this is needed: if you don't use f32/f64 in your code then the linker will see that the float formatting code is unreachable and will not link it in.

For context this cfg is wanted by Rust-for-Linux project. A few reasons that we need to remove them instead of relying on LTO:

• Linux does not yet have a good LTO support
• Linux supports out-of-tree modules, so in general even if a symbol is unused it might still be depended on and cannot be removed.

[Amanieu]

LTO is not needed for this: rustc performs the equivalent of -ffunction-sections which allows the linker to eliminate unused functions. However you make a good point about loadable modules: since a module could use floating-point numbers in theory, the linker has to keep the float formatting code just in case.

The reason excluding the formatting code works at all in your case is because most of core consists of inline functions which are only instantiated when needed. One major exception is the formatting code which is out-of-line and pre-compiled in libcore.rlib.

I'm a bit conflicted about this PR. Fundamentally, the compiler-builtins functions are required for code generated by LLVM and need to be made available. There are technical reasons for disallowing floating-point types in a kernel, but these are mainly due to issues with the use of FP registers which don't apply to code compiled with +soft-float.

This leaves two arguments for removing float formatting support:

• Code style. The kernel code style strongly discourages the use of f32, f64 and i128. However such style issues are better addressed using lints. Clippy already has a float_arithmetic lint which can be used to disallow the use of f32 and f64.
• Binary size. Since floating-point types are not used in the kernel, the float formatting logic is just dead code which is never going to be called by the kernel, but must be included by the linker just in case it is called by a kernel module. However this PR doesn't fully address this aspect either: there are many parts of core which are unlikely to ever be used in the kernel such as float parsing, many Debug impls, etc.

[nbdd0121]

I'm a bit conflicted about this PR. Fundamentally, the compiler-builtins functions are required for code generated by LLVM and need to be made available. There are technical reasons for disallowing floating-point types in a kernel, but these are mainly due to issues with the use of FP registers which don't apply to code compiled with +soft-float.

Well, given that we disallow usage of f32, f64 entirely and discourage i128 in kernel, it does not make much sense for us to add compiler-builtins as a dependency. The kernel C code can be compiled with clang but it never requires compiler-rt.

• Binary size. Since floating-point types are not used in the kernel, the float formatting logic is just dead code which is never going to be called by the kernel, but must be included by the linker just in case it is called by a kernel module. However this PR doesn't fully address this aspect either: there are many parts of core which are unlikely to ever be used in the kernel such as float parsing, many Debug impls, etc.

This PR also removes float parsing. Debug impls are less an issue because 1) sometimes it does end up being used 2) most Debug impls are generics, and the ones don't usually share a lot of code with Display and 3) it does not depend on compiler-builtin.

[Amanieu]

Hmm I think we can provisionally accept this but with the reservation that we may remove this cfg in the future and replace it with some other mechanism for disabling float support.

@bors r+

[bors]

📌 Commit 0e8c41dfd748517b55bfd6ad96d2d7e43b6352f2 has been approved by Amanieu

[nbdd0121]

I still had to rename the feature gate, please r- for now

[nbdd0121]

An option to completely disable floating point would actually be even better for us. However that change seems very big and not trivial to make, so in the short term we want at least to remove the parsing/formatting.

[scottmcm]

As requested in #86048 (comment)
@bors r-

(If I'm misunderstanding the request, please ping me and I'll re-r.)

[nbdd0121]

@nagisa it seems that parsing and formatting code are quite intertwined and it's not very easy to split the two. Currently I rename the flag to no_fp_fmt_parse. What's your opinion?

[ojeda]

Hmm I think we can provisionally accept this but with the reservation that we may remove this cfg in the future and replace it with some other mechanism for disabling float support.

That is fine, thank you. We do not mind having to change the mechanism later on if needed (at least until things mature quite a bit more on our side).

[Amanieu]

Something that might be worth exploring is having each kernel module bundle a separate copy of core to allow the linker to eliminate unused symbols. The vast majority of the code in core consists of inline functions so this should end up as a net size reduction.

@bors r+

[bors]

📌 Commit ec7292a has been approved by Amanieu

[bors]

⌛ Testing commit ec7292a with merge 9044245...

[bors]

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing 9044245 to master...