[Pixman] [PATCH] Do CPU features detection from 'constructor' function when compiled with gcc

[Andrea Canciani]

On Sun, Oct 3, 2010 at 10:52 PM, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> From: Siarhei Siamashka <siarhei.siamashka at nokia.com>
>
> There is attribute 'constructor' supported since gcc 2.7 which allows
> to have a constructor function for library initialization. This eliminates
> an extra branch for each composite operation and also helps to avoid
> complains from race condition detection tools like helgrind.

I'm working on threadsafety issues, too, but I don't have a patch ready
I pushed http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/simpleops
which adds atomic refcounting and (private, automatically called)
init/fini functions to pixman.

Currently the simpleops library (available at
http://cgit.freedesktop.org/~ranma42/simpleops )
is not complete, but in a not very distant future it should provide
some commonly
available features that with different syntax on each os/compiler (in
particular, atomics,
mutexes, integers of various sizes, constructors/destructors, thread
local storage).
It should basically be a bunch of headers to hide the
platform-specific naming and some
autotools magic to detect what is available.

I'm working on MacOS X and Ubuntu and compiling with gcc for x86_64,
so most of the
library is untested, but I expect only minor changes to be needed in
most cases, since
it is based on code from cairo and/or pixman.

I'm also working on a wip/simpleops branch in cairo, so that the same
code can be shared
between the two libraries (and moving non graphic-related code out of them).

Does this look like a viable approach for having these functionalities
in pixman?
Right now I'm mainly interested in atomic refcounting and valgrind
cleanness (threadsafe
initialization, destroying pixman_implementation's upon finalization),
but cleaning up the
TLS stuff would be nice, too.

Andrea