Re: Linux likely() unlikely() for PostgreSQL - Mailing list pgsql-hackers

From John Naylor
Subject Re: Linux likely() unlikely() for PostgreSQL
Date
Msg-id CANWCAZaKmXXNmiAtiAkcYuK68RsG6Crv9iiFnh1O0EScd9DN8Q@mail.gmail.com
Whole thread Raw
In response to Re: Linux likely() unlikely() for PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Linux likely() unlikely() for PostgreSQL
List pgsql-hackers
On Sun, Jun 30, 2024 at 10:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> In general, we have a policy of using likely/unlikely very sparingly,
> and only in demonstrably hot code paths.  This hook call certainly
> doesn't qualify as hot.

I just remembered an article I read a while back by a compiler
engineer who said that compilers have heuristics that treat NULL
pointers as "unlikely" since the most common reason to test that is so
we can actually dereference it and do something with it, and in that
case a NULL pointer is an exceptional condition. He also said it
wasn't documented so you can only see this by looking at the source
code. Instead of taking the time to verify that, I created some toy
examples and it seems to be true:

https://godbolt.org/z/dv6M5ecY5

This works all the way back to clang 3.1 and (at least, because
Compiler Explorer doesn't go back any further) gcc 3.4.6, so it's an
ancient heuristic. If we can rely on this, we could remove the handful
of statements of the form "if (unlikely(foo_ptr == NULL))" and
document it in c.h. It may be iffy to rely on an undocumented
heuristic, but it also seems silly to have a use-sparingly policy if
some of our current uses have zero effect on the emitted binary (I
haven't checked yet).



pgsql-hackers by date:

Previous
From: "cca5507"
Date:
Subject: Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state
Next
From: Meftun Cincioğlu
Date:
Subject: Enabling parallel execution for cursors