[musl] Integer only print functions support in MUSL

[musl] Integer only print functions support in MUSL

[Ram Nalamothu (QUIC)]

Hi,

On the subject line topic, is there a plan for integer only print functions support in MUSL upstream?

The newlib seems to support the same since 2004 [1] and one immediate scenario using this capability is assert function [2] in the C library itself which needs to print only the non-float types.

Applications that use integer only print functions can benefit from this capability in terms of reduced code size by avoiding floating point support implementation in the linked print functions.

I tried a quick search on the mailing list but couldn't find any previous discussions on this topic.
Would it make sense to have the similar support in MUSL as well? Would the community be open to accept patches supporting integer only print functions?

Regards,
Ram

[1] https://sourceware.org/legacy-ml/newlib/2004/msg00577.html
[2] https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/assert.c#l58

Re: [musl] Integer only print functions support in MUSL

[Markus Wichmann]

Am Wed, Jun 12, 2024 at 05:29:59PM +0000 schrieb Ram Nalamothu (QUIC):
> Hi,
>
> On the subject line topic, is there a plan for integer only print functions support in MUSL upstream?
>
> The newlib seems to support the same since 2004 [1] and one immediate scenario using this capability is assert function [2] in the C library itself which needs to print only the non-float types.
>
> Applications that use integer only print functions can benefit from this capability in terms of reduced code size by avoiding floating point support implementation in the linked print functions.
>
> I tried a quick search on the mailing list but couldn't find any previous discussions on this topic.
> Would it make sense to have the similar support in MUSL as well? Would the community be open to accept patches supporting integer only print functions?
>
> Regards,
> Ram
>
> [1] https://sourceware.org/legacy-ml/newlib/2004/msg00577.html
> [2] https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/assert.c#l58

Standard criteria for inclusion in musl have always been any kind of
standardization effort at all. Otherwise there is a risk of future
incompatible standardization. And iprintf() seems to be a newlib
exclusive; I cannot find any reference to this function outside of it.

Ciao,
Markus

Re: [musl] Integer only print functions support in MUSL

[James Y Knight]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

According to LLVM sources (LLVM knows how to transform printf variants into
iprintf variants), "iprintf and friends are only available on XCore, TCE,
and Emscripten."

I note that emscripten actually uses musl's printf implementation, and has
added iprintf support as a downstream patch.



On Wed, Jun 12, 2024 at 2:56 PM Markus Wichmann <nullplan@gmx.net> wrote:

> Am Wed, Jun 12, 2024 at 05:29:59PM +0000 schrieb Ram Nalamothu (QUIC):
> > Hi,
> >
> > On the subject line topic, is there a plan for integer only print
> functions support in MUSL upstream?
> >
> > The newlib seems to support the same since 2004 [1] and one immediate
> scenario using this capability is assert function [2] in the C library
> itself which needs to print only the non-float types.
> >
> > Applications that use integer only print functions can benefit from this
> capability in terms of reduced code size by avoiding floating point support
> implementation in the linked print functions.
> >
> > I tried a quick search on the mailing list but couldn't find any
> previous discussions on this topic.
> > Would it make sense to have the similar support in MUSL as well? Would
> the community be open to accept patches supporting integer only print
> functions?
> >
> > Regards,
> > Ram
> >
> > [1] https://sourceware.org/legacy-ml/newlib/2004/msg00577.html
> > [2]
> https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/assert.c#l58
>
> Standard criteria for inclusion in musl have always been any kind of
> standardization effort at all. Otherwise there is a risk of future
> incompatible standardization. And iprintf() seems to be a newlib
> exclusive; I cannot find any reference to this function outside of it.
>
> Ciao,
> Markus
>

[-- Attachment #2: Type: text/html, Size: 2431 bytes --]

Re: [musl] Integer only print functions support in MUSL

[Rich Felker]

On Wed, Jun 12, 2024 at 05:29:59PM +0000, Ram Nalamothu (QUIC) wrote:
> Hi,
> 
> On the subject line topic, is there a plan for integer only print
> functions support in MUSL upstream?
> 
> The newlib seems to support the same since 2004 [1] and one
> immediate scenario using this capability is assert function [2] in
> the C library itself which needs to print only the non-float types.
> 
> Applications that use integer only print functions can benefit from
> this capability in terms of reduced code size by avoiding floating
> point support implementation in the linked print functions.
> 
> I tried a quick search on the mailing list but couldn't find any
> previous discussions on this topic.
> Would it make sense to have the similar support in MUSL as well?
> Would the community be open to accept patches supporting integer
> only print functions?

My leaning is no. There is no major precedent for this, no hard *need*
(it's only an optimization hint to make up for other failed
optimizations), and to do it completely and consistently it's a
combinatoric explosion (doubling the number of printf-family
functions). At the very least you'd need (and this would be
application-unfriendly to have just these) i versions of vfprintf and
vsnprintf; everything else can be built on them.

But to get back to the point, on archs that are hard-float and don't
have an oversized soft-only long double, the size of the floating
point code in printf is around 6k. Only the most extreme environments
would warrant exploding complexity like that to save 6k. A better way
to meet their needs would probably be to provide a way to dummy-out
float support at link-time, by putting fmt_fp in its own TU and having
some trick to keep it from getting linked if you use the right
LDFLAGS. But unless there is a really good documented widespread need
for this, I can't see it making sense to do hacks like that upstream
in musl.

Rich

Re: [musl] Integer only print functions support in MUSL

[James Y Knight]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

On Wed, Jun 12, 2024 at 9:06 PM Rich Felker <dalias@libc.org> wrote:

> But to get back to the point, on archs that are hard-float and don't
> have an oversized soft-only long double, the size of the floating
> point code in printf is around 6k.


Indeed. A particular example small emscripten program which doesn't call
printf produces a 14450-byte output file.

Adding a call to `printf("%d\n", 0)` (which is optimized to a call to
iprintf by the compiler):
  increases output size by 5769 bytes.
Adding a call to `printf("%f\n", 0.0)`, using the default emscripten
printf, which has been modified to only support 'double' precision output:
  increases output size by 8413 bytes (2644 bytes more than the iprintf
version).
Adding a call to `printf("%f\n", 0.0)`, using "-s PRINTF_LONG_DOUBLE"
config option (thus enabling printf support for proper output of a 128-bit
'long double' type):
  increases output size by 13067 bytes (7298 above the iprintf version).

The 128-bit long double uses a soft-float implementation.

[-- Attachment #2: Type: text/html, Size: 1554 bytes --]

RE: [musl] Integer only print functions support in MUSL

[Ram Nalamothu (QUIC)]

Thank you, Markus and Rich, for your comments.
James, thanks for providing those code size numbers.

We can consider submitting patches towards non-float printf support if the community's stand were to change in future.

From: James Y Knight <jyknight@google.com> 
Sent: Thursday, June 13, 2024 9:34 PM
To: musl@lists.openwall.com
Cc: Ram Nalamothu (QUIC) <quic_vnalamot@quicinc.com>
Subject: Re: [musl] Integer only print functions support in MUSL

On Wed, Jun 12, 2024 at 9:06 PM Rich Felker <mailto:dalias@libc.org> wrote:
But to get back to the point, on archs that are hard-float and don't
have an oversized soft-only long double, the size of the floating
point code in printf is around 6k.

Indeed. A particular example small emscripten program which doesn't call printf produces a 14450-byte output file.

Adding a call to `printf("%d\n", 0)` (which is optimized to a call to iprintf by the compiler):
  increases output size by 5769 bytes.
Adding a call to `printf("%f\n", 0.0)`, using the default emscripten printf, which has been modified to only support 'double' precision output:
  increases output size by 8413 bytes (2644 bytes more than the iprintf version).
Adding a call to `printf("%f\n", 0.0)`, using "-s PRINTF_LONG_DOUBLE" config option (thus enabling printf support for proper output of a 128-bit 'long double' type):
  increases output size by 13067 bytes (7298 above the iprintf version).

The 128-bit long double uses a soft-float implementation.