[Ecls-list] GCC's builtins

Tobias C. Rittweiler tcr at freebits.de
Thu Feb 4 08:14:21 UTC 2010


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.

  -T.





More information about the ecl-devel mailing list