Reimplement floating-point description implementation in Swift. #82750

tbkka · 2025-07-02T22:38:27Z

This replaces the previous SwiftDtoa.cpp with the same algorithm reimplemented in Swift. It supports Float16, Float32, Float64, and Float80 (on Intel).

Performance is reasonable: In my testing (M1 and x86_64): Float16 and Float32 are a bit faster than the C version, Float64 is almost exactly the same, Float80 is a bit slower.

I think I've finally worked out the availability, though I'd appreciate someone who knows better taking a critical look.

stdlib/public/core/FloatingPointToString.swift

tbkka · 2025-07-02T22:43:44Z

CC: @stephentyrone for visibility. (I'll eventually need advice about how to deal with the availability mess here.)

stdlib/public/core/FloatingPointToString.swift

tbkka · 2025-07-29T22:09:36Z

stdlib/public/core/FloatingPointToString.swift

+// ================================================================
+
+// Support Legacy ABI on top of new implementation
+@_silgen_name("swift_float32ToString2")


@stephentyrone Do we really need to keep these legacy ABIs? The old implementation went to some effort to preserve them, but I'm not sure why.

tbkka · 2025-07-30T15:57:23Z

stdlib/public/core/FloatingPointToString.swift

+  value d: Float64,
+  buffer utf8Buffer: inout MutableSpan<UTF8.CodeUnit>) -> Range<Int>
+{
+    if #available(macOS 9999, *) {


@al45tair What's the right way to write this dance? It is here only to try to safely call the other functions in this same file. But as written here, it ends up doing a runtime availability check, which I would rather avoid as it's entirely pointless.

You could go with if #available(StdlibDeploymentTarget 6.0) here and annotate the things it uses with @available(StdlibDeploymentTarget 6.0). That should avoid any runtime tests (everywhere, I think, except possibly if one of this is inlineable and we're back-deploying). I picked 6.0 because that corresponds to macOS 15, and I think there are some existing annotations in the file suggesting that version?

tbkka · 2025-08-01T23:18:13Z

stdlib/public/core/FloatingPointToString.swift

+  value f: Float16,
+  buffer utf8Buffer: inout MutableSpan<UTF8.CodeUnit>) -> Range<Int>
+{
+    if #available(SwiftStdlib 6.2, *) {


Does this necessarily do a runtime OS version check? How does one avoid that?

In effect, we are re-implementing an old API using new ones. The new ones are always "available" in the sense that they're always compiled -- the availability on the new APIs is only there to inform clients of their back-deployment options. (Our availability notions seem to mistakenly conflate "when something was introduced" with "what requirements it has".)

It won't do a runtime version check if the target that we're building for is high enough — it doesn't always do it.

Entirely coincidentally, I was thinking this morning (before I'd seen this comment) that we really should have both @available() and @requires() and that we were really conflating exactly those two notions.

Perhaps we should add @introduced() and @requires() and document that @available() implies both of the others? That would give a migration path.

compnerd

This seems to be missing the addition of the new file to swiftCore in the new runtimes build.

tbkka · 2025-08-04T15:57:49Z

This seems to be missing the addition of the new file to swiftCore in the new runtimes build.

How do I fix that? I'm not familiar with "the new runtimes build."

etcwilde · 2025-08-04T18:58:07Z

How do I fix that? I'm not familiar with "the new runtimes build."

Add FloatingPointToString.swift to Runtimes/Core/core/CMakeLists.txt

swift/Runtimes/Core/core/CMakeLists.txt

Line 82 in e690f1d

FloatingPoint.swift

tbkka · 2025-08-04T19:09:12Z

@swift-ci Please test

tbkka · 2025-08-04T20:23:20Z

@swift-ci Please test

tbkka · 2025-08-04T23:23:29Z

@etcwilde Now we're failing in CI for AVR. Clearly, a 16-bit platform does not want this file. How do I exclude it from those?

stdlib/public/core/FloatingPointToString.swift

tbkka · 2025-08-05T23:03:55Z

@swift-ci Please test

tbkka · 2025-08-05T23:05:07Z

I tweaked one place where 32-bit int was assumed but not specified. This may let it build on AVR.

tbkka · 2025-08-06T21:06:56Z

32-bit WASM tests revealed a problem with Float32 formatting on 32-bit CPUs. There also seems to be some problem with Float64 and NaNs that I'm trying to track down.

tbkka · 2025-08-06T21:11:56Z

@swift-ci Please test Linux

tbkka · 2025-08-11T22:00:21Z

@swift-ci Please test Linux

Note: This is still incomplete. I need to finish porting the Float16 and Float80 support before it can fully replace the existing C implementation.

tbkka · 2025-08-13T14:06:06Z

@swift-ci Please test

tbkka · 2025-08-13T15:07:30Z

@natecook1000 I'm toying with the idea of restructuring this a bit. Basically, making the new source file directly implement extension Float# : CustomDebugStringConvertible without the layers of indirection. Any thoughts?

tbkka · 2025-08-13T21:41:25Z

stdlib/public/core/FloatingPointTypes.swift.gyb

-    return unsafe buffer.withBytes { (bufferPtr) in
-      unsafe String._fromASCII(
-        UnsafeBufferPointer(start: bufferPtr, count: length))
+    if #available(SwiftStdlib 6.2, *) {


@tshortli @al45tair -- In my local testing, it appears that this check results in a call to __isPlatformVersionAtLeast which takes a full 1/3 of the run time for debugDescription. This shouldn't be necessary at all -- the implementation here has no dependencies outside of the standard library that we're part of. How can we eliminate this?

Do you get a different outcome if you use _unreachable() instead of fatalError()?

Local stdlib builds set the deployment target to something way too old, see 144244211

You could also use StdlibDeploymentTarget 6.2 here (but as before, you might end up having to move more things to StdlibDeploymentTarget 6.2 as a result). That will get rid of the check, because when you build locally, you'll be testing for the target you're building for.

That would let you test the performance sensibly here, I think.

You can override the default deployment target when building locally by passing something like --darwin-deployment-version-osx 26 to build-script, if you just want to look at performance locally.

build-script should really do this by default, because the alternative is even less representative of the way the stdlib actually gets built.

You could also use StdlibDeploymentTarget 6.2 here (but as before, you might end up having to move more things to StdlibDeploymentTarget 6.2 as a result).

Nope. That doesn't work for InlineArray, at least not with a stock build-script -rA invocation, since "value generics are only available on macOS 26." I discussed this in #83710. If I landed that, then I could duplicate InlineArray to make internal _InlineArray which would not need any availability restrictions at all. Using the same pattern to create internal _MutableSpan would probably just eliminate all of the availability checks in this code.

I've not experimented with _unreachable() yet.

I'm playing with build-script incantations to see what other options exist.

... something like --darwin-deployment-version-osx 26 to build-script, if you just want to look at performance locally

Sure, but that still misses the point: Nothing in this code requires macOS 26. Everything it needs is in libswiftCore. The runtime host version is irrelevant.

It would let you look at performance locally without the version checks getting in the way. It doesn’t solve the larger issue, of course.

natecook1000 · 2025-08-18T19:36:42Z

stdlib/public/core/FloatingPointTypes.swift.gyb

-      unsafe String._fromASCII(
-        UnsafeBufferPointer(start: bufferPtr, count: length))
+    if #available(SwiftStdlib 6.2, *) {
+        var buffer = InlineArray<64, UTF8.CodeUnit>(repeating: 0)


Any reason not to initialize this to 0x30 instead of zero?

A-ha! Nice catch indeed! Yes, that would eliminate some work later on.

For example, this avoids the need to do any explicit byte-by-byte writes when expanding "123" out to "123000000.0". This also required reworking the "back out extra digits" process for Float64 to ensure the unused digits get written as '0' characters instead of null bytes.

tbkka commented Jul 2, 2025

View reviewed changes

stdlib/public/core/FloatingPointToString.swift Outdated Show resolved Hide resolved

tbkka force-pushed the tbkka-swift-floatingpointtostring branch from 295114c to 28ca1f0 Compare July 29, 2025 19:50

tbkka commented Jul 29, 2025

View reviewed changes

stdlib/public/core/FloatingPointToString.swift Outdated Show resolved Hide resolved

tbkka commented Jul 29, 2025

View reviewed changes

tbkka commented Jul 30, 2025

View reviewed changes

This was referenced Jul 31, 2025

Embedded Swift: Numeric Printing & Parsing #83457

Open

Embedded Swift: Float Printing #83460

Open

rauhul added this to Embedded Swift Aug 1, 2025

rauhul moved this to In Progress in Embedded Swift Aug 1, 2025

tbkka force-pushed the tbkka-swift-floatingpointtostring branch from 28ca1f0 to 5bfe1c1 Compare August 1, 2025 22:04

tbkka marked this pull request as ready for review August 1, 2025 23:13

tbkka requested review from mikeash, a team, rjmccall, compnerd, etcwilde, edymtt and justice-adams-apple as code owners August 1, 2025 23:13

tbkka commented Aug 1, 2025

View reviewed changes

compnerd reviewed Aug 1, 2025

View reviewed changes

tbkka force-pushed the tbkka-swift-floatingpointtostring branch from 5b20b0b to cac5983 Compare August 4, 2025 19:08

natecook1000 reviewed Aug 5, 2025

View reviewed changes

stdlib/public/core/FloatingPointToString.swift Outdated Show resolved Hide resolved

tbkka added 18 commits August 12, 2025 13:35

Reimplement floating-point description implementation in Swift.

396f345

Note: This is still incomplete. I need to finish porting the Float16 and Float80 support before it can fully replace the existing C implementation.

Add Float16 support to the Swift implementation

4ee98f1

Float16 tweaks: balancing safety and performance

556180e

Float32/64 safety improvements

3d55609

Initial Float80 support + some general reorganization and commenting

35298af

Float80 performance

9256fb3

Comment updates

7fcb728

Fix availability

79ab38d

Remove old C implementation

37f1841

Add FP-to-string support to core library

85fca4c

Match up conditional for Float80 support

d89a33a

Try to match stdlib coding conventions

20636ea

Remove a layer of indirection

e0e4abe

Fix build when Int is 16 bits

446c9b8

Fix Float32 formatting on 32-bit architectures

4069a58

Remove extra semicolons

912583a

Try to fix a crash only seen so far on WASI32

7902b41

Minor safety and performance tweaks

deccd0a

tbkka force-pushed the tbkka-swift-floatingpointtostring branch from eefe4ff to deccd0a Compare August 13, 2025 14:05

tbkka commented Aug 13, 2025

View reviewed changes

tbkka mentioned this pull request Aug 14, 2025

Allow value generics within the stdlib #83710

Open

natecook1000 reviewed Aug 18, 2025

View reviewed changes

Reimplement floating-point description implementation in Swift. #82750

Are you sure you want to change the base?

Reimplement floating-point description implementation in Swift. #82750

Conversation

tbkka commented Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

tbkka commented Jul 2, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

compnerd left a comment

Choose a reason for hiding this comment

Uh oh!

tbkka commented Aug 4, 2025

Uh oh!

etcwilde commented Aug 4, 2025

Uh oh!

tbkka commented Aug 4, 2025

Uh oh!

tbkka commented Aug 4, 2025

Uh oh!

tbkka commented Aug 4, 2025

Uh oh!

Uh oh!

tbkka commented Aug 5, 2025

Uh oh!

tbkka commented Aug 5, 2025

Uh oh!

tbkka commented Aug 6, 2025

Uh oh!

tbkka commented Aug 6, 2025

Uh oh!

tbkka commented Aug 11, 2025

Uh oh!

tbkka commented Aug 13, 2025

Uh oh!

tbkka commented Aug 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikeash Aug 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tbkka commented Jul 2, 2025 •

edited

Loading

mikeash Aug 19, 2025 •

edited

Loading