Hello Robert,
if (arg1 == PG_INT32_MIN)
if (arg2 == 0 || arg2 == PG_INT32_MIN)
And possibly a "likely" on the while.
I don't think decoration the code with likely() and unlikely() all
over the place is a very good idea.
Odds are good that we'll end up with a bunch that are actually
non-optimal, and nobody will ever figure it out because it's hard to
figure out.
My 0.02€: I'd tend to disagree.
Modern pipelined processors can take advantage of speculative execution on
branches, so if you know which branch is the more likely it can help.
Obviously if you get it wrong it does not, but for the above cases it
seems to me that they are rather straightforward.
It also provides some "this case is expected to be exceptional" semantics
to people reading the code.
I have a hard time believing that we're going to be much
worse off if we just write the code normally.
I think that your point applies to more general programming in postgres,
but this is not the context here.
For low-level arithmetic code like this one, with tests and loops
containing very few hardware instructions, I think that helping compiler
optimizations is a good idea.
Maybe in the "while" the compiler would assume that it is going to loop
anyway by default, so it may be less useful there.
--
Fabien.
