Hi Adhemerval,

On 2021/10/6 1:15 AM, Adhemerval Zanella wrote:
>> I'm not sure if defining 'enum dso_sort_algorithm' is really needed?
>> Is __builtin_unreachable() that undesirable?
> The tunables code should already sanitize the input and returns the
> possible algorithms as a type, instead of a number.  I think it is
> clear to work with predefined type, than hint the compiler explicitly.

Okay, understood.

>> Also, the final code should probably add __glibc_likely() to the default
>> algorithm case.
> Sometime I think we abuse the __glibc_{un}likely, specially on short code
> like that.  But please reinstate it if you see that it does improve code
> generation.

I have re-done some microbenchmarking using hp-timing facilities, and it appears
that __glibc_likely() helps a "little" bit overall (slightly more consistent
on powerpc64le, a little less on my own x86_64 desktop), at worst no apparent
improvement. So I've added it back.

The attached patch is basically the version on the azanella/dso-opt branch, plus
the above __glibc_likely() addition, plus a little bit of editing of comments.
Rebased and re-tested, is this okay for master?

Thanks,
Chung-Lin