[v1,2/2] x86_64: Add {u}int_fast defs ideal for x86_64

Message ID 20220411010913.1061799-2-goldstein.w.n@gmail.com
State Rejected
Headers
Series [v1,1/2] stdlib: Refactor {u}int_fast defs in stdint |

Checks

Context Check Description
dj/TryBot-apply_patch success Patch applied to master at the time it was sent
dj/TryBot-32bit success Build for i686

Commit Message

Noah Goldstein April 11, 2022, 1:09 a.m. UTC
  {u}int_fast{16|32} should never use 64-bit types. 64-bit instructions
often use more code size (REX prefix) and a variety of instructions are
slower on many implementations (div, bswap, etc...).

Full xcheck passes on x86_64.
---
 sysdeps/x86_64/int-fast.h | 50 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 sysdeps/x86_64/int-fast.h
  

Comments

Adam Sampson April 11, 2022, 2:15 a.m. UTC | #1
Noah Goldstein via Libc-alpha <libc-alpha@sourceware.org> writes:

> {u}int_fast{16|32} should never use 64-bit types. 64-bit instructions
> often use more code size (REX prefix) and a variety of instructions
> are slower on many implementations (div, bswap, etc...).

Isn't that going to cause ABI breakage in other libraries, though?
For example, the jasper JPEG2000 decoder library uses stdint.h's
uint_fast32_t in its public API, and the HDF5 scientific data library
includes constants for the sizes of various types including *int*fast*.

Thanks,
  
Florian Weimer April 11, 2022, 6:34 a.m. UTC | #2
* Adam Sampson via Libc-alpha:

> Noah Goldstein via Libc-alpha <libc-alpha@sourceware.org> writes:
>
>> {u}int_fast{16|32} should never use 64-bit types. 64-bit instructions
>> often use more code size (REX prefix) and a variety of instructions
>> are slower on many implementations (div, bswap, etc...).
>
> Isn't that going to cause ABI breakage in other libraries, though?
> For example, the jasper JPEG2000 decoder library uses stdint.h's
> uint_fast32_t in its public API, and the HDF5 scientific data library
> includes constants for the sizes of various types including *int*fast*.

Agreed, it's too late for such changes.

Thanks,
Florian
  
Joseph Myers April 14, 2022, 10:24 p.m. UTC | #3
On Sun, 10 Apr 2022, Noah Goldstein via Libc-alpha wrote:

> {u}int_fast{16|32} should never use 64-bit types. 64-bit instructions
> often use more code size (REX prefix) and a variety of instructions are
> slower on many implementations (div, bswap, etc...).

Apart from the other issues discussed with this patch, installed headers 
should not be specific to either x86_64 or 32-bit x86; such headers, where 
architecture-specific, should go in an x86/ sysdeps directory and contain 
appropriate conditionals within the header, so a single set of installed 
headers works with a multilibbed compiler.

> +# include <sysdeps/generic/int-fast.h>

And an installed header can't do that sort of thing, because only a single 
version of any such header gets installed.  If you want to include a 
generic file it has to have a different name, with both being installed 
(cf. bits/mman-*.h, for example).
  
Noah Goldstein April 14, 2022, 10:44 p.m. UTC | #4
On Thu, Apr 14, 2022 at 5:24 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Sun, 10 Apr 2022, Noah Goldstein via Libc-alpha wrote:
>
> > {u}int_fast{16|32} should never use 64-bit types. 64-bit instructions
> > often use more code size (REX prefix) and a variety of instructions are
> > slower on many implementations (div, bswap, etc...).
>
> Apart from the other issues discussed with this patch, installed headers
> should not be specific to either x86_64 or 32-bit x86; such headers, where
> architecture-specific, should go in an x86/ sysdeps directory and contain
> appropriate conditionals within the header, so a single set of installed
> headers works with a multilibbed compiler.
>
> > +# include <sysdeps/generic/int-fast.h>
>
> And an installed header can't do that sort of thing, because only a single
> version of any such header gets installed.  If you want to include a
> generic file it has to have a different name, with both being installed
> (cf. bits/mman-*.h, for example).

Good info to have but the patches have been drop for the ABI concerns.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
  

Patch

diff --git a/sysdeps/x86_64/int-fast.h b/sysdeps/x86_64/int-fast.h
new file mode 100644
index 0000000000..8f341de646
--- /dev/null
+++ b/sysdeps/x86_64/int-fast.h
@@ -0,0 +1,50 @@ 
+/* Copyright (C) 2022 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, see
+   <https://www.gnu.org/licenses/>.  */
+
+#ifndef _INT_FAST_X86_64_H
+#define _INT_FAST_X86_64_H	1
+
+#define __HAS_INT_FAST_DEFS	1
+
+/* Signed.  */
+typedef signed char		int_fast8_t;
+/* On x86_64 32-bit instructions are almost always fastest.  */
+typedef int			int_fast16_t;
+typedef int			int_fast32_t;
+typedef long int		int_fast64_t;
+
+/* Unsigned.  */
+typedef unsigned char		uint_fast8_t;
+/* On x86_64 32-bit instructions are almost always fastest.  */
+typedef unsigned int		uint_fast16_t;
+typedef unsigned int		uint_fast32_t;
+typedef unsigned long int	uint_fast64_t;
+
+
+# define __INT_FAST8_BASE		INT8
+# define __INT_FAST16_BASE		INT32
+# define __INT_FAST32_BASE		INT32
+# define __INT_FAST64_BASE		INT64
+
+# define __UINT_FAST8_BASE		UINT8
+# define __UINT_FAST16_BASE		UINT32
+# define __UINT_FAST32_BASE		UINT32
+# define __UINT_FAST64_BASE		UINT64
+
+# include <sysdeps/generic/int-fast.h>
+
+#endif