[Ecls-list] GCC's builtins

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Wed Feb 3 23:39:06 UTC 2010


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

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100204/fb807706/attachment.html>


More information about the ecl-devel mailing list