[Ecls-list] GCC's builtins

[Gabriel Dos Reis]

On Thu, Feb 4, 2010 at 2:14 AM, Tobias C. Rittweiler <tcr at freebits.de> wrote:
> Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at googlemail.com> writes:
>
>> I am experimenting again with tagging certain function and branches using
>> GCC's builtin attributes.
>>
>> For instance, FEprogram_error is now tagged __attribute__((noreturn))
>> indicating that it is a function that does not return.
>>
>> These attributes existed before in ECL's code, but GCC was broken at some
>> point and interpreted "noreturn" also as "nolongjmp". This broke code that
>> captures errors using UNWIND-PROTECT, HANDLER-CASE, etc.
>>
>> As of GCC 4.* a "noreturn" function is explicitely allowed to use "longjmp"
>> to return to the caller. I would love to simply uncomment all
>> __attribute__((noreturn)), but 1) there is the chance that this is still
>> broken in some corner cases or 2) some people may try to build ECL using GCC
>> 3.4, for instance. Hence my approach is now conservative, using ((noreturn))
>> only on functions that are called from other functions that do not use those
>> protection mechanisms. Perhaps this is too conservative.
>>
>> The other optimization is using __builtin_expect() to denote branches of
>> code which are really rare, such as errors.
>>
>> The overall gain is right now marginal, in total, but it is quite
>> significant in some cases because those function calls and rare branches are
>> moved out of the function core, which may become slimmer and more efficient.
>> In many cases, for instance, GCC moves all calls to the error functions to
>> the end, much like SBCL does.
>>
>> Help is welcome in doing this perhaps in a more civilized way, allowing more
>> attributes for more recent versions of GCC, or improving the aestetics of
>> the resulting code via C macros -- __builtin_expect() is definitely ugly.
>>
>> Juanjo
>
> You could take a look into
> linux-kernel-headers/include/linux/compiler{,-gcc,gcc4}.h for what the
> kernel guys came up with. E.g. see the `likely', `unlikely' macros.

Indeed.  But, if you do, please make sure it is prefixed (e.g. ecl_likely.)
Some systems tend to define such macros -- I ran into that issue about
4 years ago.

BTW, GCC attributes can make codes very ugly to read.  I don't have
a general remedy for that, except adopting the style we use in GCC's own
source code.

-- Gaby