[ltt-dev] [PATCH 07/11] add uatomic_gcc.h, use it for default definitions

[Mathieu Desnoyers]

* Paolo Bonzini (pbonzini at redhat.com) wrote:
> On 02/15/2010 05:23 PM, Mathieu Desnoyers wrote:
>> 1) We choose to discard support for old compilers on all architectures.
>>    + simple/clean code
>>    + easier to maintain
>>    + less error-prone, using widely tested gcc builtins.
>>    - liburcu become incompatible with lots of systems still being used today.
>
> This is v1 of my patchset, and I understand it's too much.  (To be  
> precise v1 was a bit less strict, as x86 and SPARC64 would remain  
> compatible with old compilers).
>
> It is too aggressive considering the other possibilities.
>
>> 2) We choose to stick to custom per-architecture macros (only).
>>    - more complex code.
>>    - more code to maintain.
>>    - more testing needed because we are not using gcc builtins.
>>    - requires an initial effort to port liburcu to new architectures.
>>    + provides support for gcc compilers back to early 3.x versions.
>>    + test suites covers all gcc versions (no special-cases for old vs new
>>      versions). Ensures that the code does not get bitrotten by not being
>>      tested.
>
> This is the status quo, besides the fact that S390 and SPARC64 are  
> already using GCC builtins in non-public headers.

These non-public headers could possibly be changed to remove the builtin
dependencies.

>
>> 3) We choose to stick to custom per-arch macros, and use gcc builtins for
>>     architectures for new architectures we want to support.
>>     Same ± as (2), with this distinction:
>>     + diminish initial port effort, because we can provide support for
>>       new architectures (except for old compilers) quickly by using builtins.
>>
>> 4) Detect compiler versions with the precompiler. Use builtins for new
>>     compilers, and explicit declarations for old compilers.
>>    - more complex code.
>>    - more code to maintain.
>>    - more testing needed because we are not using gcc builtins.
>>    - requires an initial effort to port liburcu to new architectures.
>>    - test suites have to test for many compiler versions. Chances are
>>      that the "old compiler compatibility" code will get much less
>>      tested. This is, IMHO, a recipe for a disaster, as bugs will creap
>>      in and testing will be hard.
>>    + provides support for gcc compilers back to early 3.x versions.
>
> (5) We choose to discard support for old compilers on all architectures,  
> but fallback to non-_LGPL_SOURCE on all compilers
>     + simple/clean code
>     + easier to maintain
>     + less error-prone (even though it's not really possible to use GCC
>       builtins everywhere)
>    - liburcu becomes less efficient on lots of systems in use today

Well, a supplementary problem with this approach is that people who need
to build their libraries themself for architectures where gcc is not
up-to-date will hit a wall. Not everyone has the luxury of using
pre-packaged and pre-built versions of the libraries, especially in the
embedded field.

>
>> The current approach for liburcu is (2), but I think it's good to move
>> to (3). However, I really dislike (4) because it makes testing much
>> harder, and (1) is, I think, a no-go for a library meant to be usable on
>> the large ecosystem of systems we have today (some with old compilers).
>
> Exactly.
>
> (3) is the most balanced and reasonable as things stand now.
>
> (4) is definitely going to bitrot sooner than later (it would cost just  
> an #ifdef...#endif around what we have now, but the problem of course is  
> what goes inside the #ifdef).
>
> I was thinking of doing (3) with the additional twist that S390 would  
> count as a "new architecture".  On it, GCC is providing really  
> everything that is needed and furthermore, unlike PPC, your testers  
> surely have a new-enough GCC because they're using api_gcc.h.

Hrm. As things stand, I would recommend plainly going with (3), using
gcc builtins only for the new architectures which are not supported at
the moment, being ready to merge compatibility code for these
architectures if we see the need for it at some point.

From this point of view, moving s390 from the custom operations to gcc
builtins seems like a step backward. I'd prefer to look into the
api_gcc.h issues and fix those so we can ensure that sparc64 and s390
are OK with older gcc.

We should also put a statement in the README file stating which
compilers we target.

>
> Switching from (3) to (5) can be done later, after evaluating more  
> carefully the pros and cons.  What do you think?

As I pointed out above, the problem with (5) is that embedded developers
who build their own libraries will run into toolchain version issues.

Thanks,

Mathieu

>
> Paolo
>

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68