Re: Word For Today: “Uglification”

On 15/03/2024 01:11, Keith Thompson wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

For context, here's the entire file from my system (Ubuntu 24.0.4,
package libc6-dev:amd64 2.35-0ubuntu3.6).  I get the impression that the
author(s) decided not to use memset to avoid the required #include,
which might increase compilation times for code that indirectly includes
this header.  (I offer no opinion on whether that's a good tradeoff.)
>
Note that __FD_ZERO is very clearly *not* intended to be invoked by
arbitrary code.
>
```

[code snipped]

```
>

>
That code is only selected if it is not compiled with
gcc.  If it is gcc 2 or later, the header file uses
>
# define __FD_ZERO(fdsp) \
   do {                                                                        \
     int __d0, __d1;                                                           \
     __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS                         \
                           : "=c" (__d0), "=D" (__d1)                          \
                           : "a" (0), "0" (sizeof (fd_set)                     \
                                           / sizeof (__fd_mask)),              \
                             "1" (&__FDS_BITS (fdsp)[0])                       \
                           : "memory");                                        \
   } while (0)

 Oh?  I don't see that code anywhere in the current glibc sources, in any
older version of bits/select.h, or anywhere under /usr/include on my
system.
 

I see it in my older Mint system (based on Ubuntu bionic 18.04 LTS), but not my newer one (based on Ubuntu jammy 22.04 LTS).  So it looks like was an optimisation that was useful in the past, but newer gcc gives the same or better code from the pure C code.  Keeping it in C rather than inline assembly gives the compiler more information, even if the generated object code is still the same, so that's always a good thing.
(And full memory clobbers are undesirable in performance code because it can mean the compiler loses useful knowledge or has to re-load other data from memory.)