gh-139353: Rename formatter_unicode.c to unicode_formatter.c

[vstinner]

• Move Python/formatter_unicode.c to Objects/unicode_formatter.c.
• Move Objects/stringlib/localeutil.h content into unicode_formatter.c. Remove localeutil.h.
• Move _PyUnicode_InsertThousandsGrouping() to unicode_formatter.c and mark the function as static.
• Rename unicode_fill() to _PyUnicode_Fill() and export it in pycore_unicodeobject.h.

• Issue: Split large Objects/unicodeobject.c file into smaller files #139353

[vstinner]

@serhiy-storchaka: Is it what you asked for?

[serhiy-storchaka]

Well, lets go.

Please check that the formatting code that uses _PyUnicode_InsertThousandsGrouping() does not struggle due to non-inlined _PyUnicode_Fill().

[serhiy-storchaka]

Are you sure that it will be inlined? Maybe keep static inline unicode_fill() and add a wrapper _PyUnicode_Fill()?

[vstinner]

Maybe keep static inline unicode_fill() and add a wrapper _PyUnicode_Fill()?

Ok, I implemented _PyUnicode_Fill() as a static inline function. So the compiler can decide to inline it or not.

[vstinner]

Please check that the formatting code that uses _PyUnicode_InsertThousandsGrouping() does not struggle due to non-inlined _PyUnicode_Fill().

I checked the Python 3.14 executable on Fedora which is built with PGO+LTO. I looked at _PyUnicode_InsertThousandsGrouping() x86-64 assembly code in gdb. I found:

...
   0x00007ffff7abe483 <+339>:	call   0x7ffff7abe700 <unicode_fill.lto_priv.0>
...
   0x00007ffff7abe665 <+821>:	call   0x7ffff7abe700 <unicode_fill.lto_priv.0>
...

So in the Fedora package at least, unicode_fill() is not inlined in _PyUnicode_InsertThousandsGrouping(). Inlining is not always a good idea, it can be bad for the L1-instruction cache and puts more pressure on register allocation. I trust the compiler to decide if it's a good idea to inline or not.

[serhiy-storchaka]

Oh, I did not suggest to make it inline. I only asked if this makes noticeable difference. Locale specific formatting is complex, so I think it would not, even if it was inlined previously, but we should check.

Anyway, LGTM. 👍