* [PATCH] ftw.c: Use unlikely for unlikely taken branches such that taken ones are placed closer
@ 2023-10-03 3:40 James Tirta Halim
2023-10-03 6:28 ` Xi Ruoyao
0 siblings, 1 reply; 4+ messages in thread
From: James Tirta Halim @ 2023-10-03 3:40 UTC (permalink / raw)
To: libc-alpha; +Cc: James Tirta Halim
---
io/ftw.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/io/ftw.c b/io/ftw.c
index a72c7d5171..94fb2842d2 100644
--- a/io/ftw.c
+++ b/io/ftw.c
@@ -209,7 +209,7 @@ ftw_allocate (struct ftw_data *data, size_t newsize)
void *newp = realloc (data->dirstreams, data->maxdir
* sizeof (struct dir_data *)
+ newsize);
- if (newp == NULL)
+ if (__glibc_unlikely(newp == NULL))
return false;
data->dirstreams = newp;
data->dirbufsize = newsize;
@@ -255,7 +255,7 @@ static int
add_object (struct ftw_data *data, struct STRUCT_STAT *st)
{
struct known_object *newp = malloc (sizeof (struct known_object));
- if (newp == NULL)
+ if (__glibc_unlikely(newp == NULL))
return -1;
newp->dev = st->st_dev;
newp->ino = st->st_ino;
@@ -287,7 +287,7 @@ open_dir_stream (int *dfdp, struct ftw_data *data, struct dir_data *dirp)
size_t bufsize = 1024;
char *buf = malloc (bufsize);
- if (buf == NULL)
+ if (__glibc_unlikely(buf == NULL))
result = -1;
else
{
@@ -298,12 +298,12 @@ open_dir_stream (int *dfdp, struct ftw_data *data, struct dir_data *dirp)
while ((d = __readdir64 (st)) != NULL)
{
size_t this_len = NAMLEN (d);
- if (actsize + this_len + 2 >= bufsize)
+ if (glibc_unlikely(actsize + this_len + 2 >= bufsize))
{
char *newp;
bufsize += MAX (1024, 2 * this_len);
newp = (char *) realloc (buf, bufsize);
- if (newp == NULL)
+ if (__glibc_unlikely(newp == NULL))
{
/* No more memory. */
int save_err = errno;
@@ -325,7 +325,7 @@ open_dir_stream (int *dfdp, struct ftw_data *data, struct dir_data *dirp)
/* Shrink the buffer to what we actually need. */
void *content = realloc (buf, actsize);
data->dirstreams[data->actdir]->content = content;
- if (content == NULL)
+ if (__glibc_unlikely(content == NULL))
{
int save_err = errno;
free (buf);
--
2.42.0
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ftw.c: Use unlikely for unlikely taken branches such that taken ones are placed closer
2023-10-03 3:40 [PATCH] ftw.c: Use unlikely for unlikely taken branches such that taken ones are placed closer James Tirta Halim
@ 2023-10-03 6:28 ` Xi Ruoyao
2023-10-03 7:47 ` Andreas Schwab
0 siblings, 1 reply; 4+ messages in thread
From: Xi Ruoyao @ 2023-10-03 6:28 UTC (permalink / raw)
To: James Tirta Halim, libc-alpha
On Tue, 2023-10-03 at 10:40 +0700, James Tirta Halim wrote:
> ---
> io/ftw.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/io/ftw.c b/io/ftw.c
> index a72c7d5171..94fb2842d2 100644
> --- a/io/ftw.c
> +++ b/io/ftw.c
> @@ -209,7 +209,7 @@ ftw_allocate (struct ftw_data *data, size_t newsize)
> void *newp = realloc (data->dirstreams, data->maxdir
> * sizeof (struct dir_data *)
> + newsize);
> - if (newp == NULL)
> + if (__glibc_unlikely(newp == NULL))
AFAIK the compiler should automatically mark malloc and realloc failures
as unlikely. On x86_64 GCC 7 predicts the probability of such a failure
1.74%, and GCC 13 predicts it 0.04%.
/* snip */
> @@ -298,12 +298,12 @@ open_dir_stream (int *dfdp, struct ftw_data *data, struct dir_data *dirp)
> while ((d = __readdir64 (st)) != NULL)
> {
> size_t this_len = NAMLEN (d);
> - if (actsize + this_len + 2 >= bufsize)
> + if (glibc_unlikely(actsize + this_len + 2 >= bufsize))
It seems only this one might be mispredicted by GCC. But there should
be a white space between "glibc_unlikely" and "(". And should it be
"__glibc_unlikely" (what's the difference between __glibc_unlikely and
glibc_unlikely)?
--
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ftw.c: Use unlikely for unlikely taken branches such that taken ones are placed closer
2023-10-03 6:28 ` Xi Ruoyao
@ 2023-10-03 7:47 ` Andreas Schwab
0 siblings, 0 replies; 4+ messages in thread
From: Andreas Schwab @ 2023-10-03 7:47 UTC (permalink / raw)
To: Xi Ruoyao; +Cc: James Tirta Halim, libc-alpha
On Okt 03 2023, Xi Ruoyao wrote:
> (what's the difference between __glibc_unlikely and glibc_unlikely)?
The difference is that the latter does not exist.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH] ftw.c: Use unlikely for unlikely taken branches such that taken ones are placed closer
@ 2023-10-03 10:44 Wilco Dijkstra
0 siblings, 0 replies; 4+ messages in thread
From: Wilco Dijkstra @ 2023-10-03 10:44 UTC (permalink / raw)
To: Xi Ruoyao, tirtajames45; +Cc: 'GNU C Library'
Hi,
> @@ -298,12 +298,12 @@ open_dir_stream (int *dfdp, struct ftw_data *data, struct dir_data *dirp)
> while ((d = __readdir64 (st)) != NULL)
> {
> size_t this_len = NAMLEN (d);
> - if (actsize + this_len + 2 >= bufsize)
> + if (glibc_unlikely(actsize + this_len + 2 >= bufsize))
> It seems only this one might be mispredicted by GCC. But there should
> be a white space between "glibc_unlikely" and "(". And should it be
> "__glibc_unlikely"
If GCC's static predictor gets this case wrong, it should be reported as a bug.
An if-statement containing a call should get lower probability in a loop -
the call to realloc implies a rare case to increase buffer space.
Note we should use __glibc_unlikely only in performance critical code, not in
code like this.
Cheers,
Wilco
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-10-03 10:44 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-03 3:40 [PATCH] ftw.c: Use unlikely for unlikely taken branches such that taken ones are placed closer James Tirta Halim
2023-10-03 6:28 ` Xi Ruoyao
2023-10-03 7:47 ` Andreas Schwab
2023-10-03 10:44 Wilco Dijkstra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).