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

[compudj@krystal.dyndns.org (Mathieu Desnoyers)]

* Paolo Bonzini (pbonzini at redhat.com) wrote:
> On 02/15/2010 03:55 PM, Mathieu Desnoyers wrote:
>> * Paolo Bonzini (pbonzini at redhat.com) wrote:
>>> On 02/14/2010 03:45 PM, Mathieu Desnoyers wrote:
>>>>>>   - if cmpxchg is present, use it to implement xchg and add_return;
>>>>
>>>> Not sure I understand this comment, and not sure it matches the patch.
>>>> x86 has xchg() which is faster than a cmpxchg-based fallback, and you
>>>> seem to leave the code as-is. Can you elaborate ?
>>>
>>> Each per-architecture file can provide its own xchg and add_return which
>>> are then used instead of the defaults.  For example, x86 uses entirely
>>> custom code, and PPC uses its own implementation of xchg (since it is
>>> also much faster than cmpxchg on ll/sc machines).
>>
>> OK. Please update the changelog comment with the information above.
>
> Will do.
>
>>>> Starting from which gcc versions does these __sync_* builtins work ?
>>>> (question applies for the builtin memory barrier too).
>>>
>>> The builtins appeared in 4.2, but they were backported to 4.1 by some
>>> vendors.
>>>
>>> Note that on SPARC64 and S390 they were already needed to build the
>>> library because the tests used them.
>>
>> For __builtin_trap() I suspect. This could be changed if needed.
>
> No, for api_gcc.h.

Well, api_gcc is only used for some of the library internal tests. It
should not be considered as one of the "public" headers. I'm afraid I
don't see which builtins you refer to. Could you be more specific ?

>
>>> After this, a client that is interested in using an older GCC can thus
>>> use _LGPL_SOURCE if it finds a compiler that is not new enough.  I can
>>> also make this automatic if you prefer.
>>
>> Hrm, that's a problem. We cannot just say "hey, update the test systems
>> you are working with to newer compilers" to people who often only borrow
>> these systems and have to deal with the very often deprecated toolchains
>> available. This is the case for a 64-core POWER5+ we are doing testing
>> on: we're stuck with an old gcc.
>
> Ok, I won't update PPC then.

Well, the fact that we personally test on a POWER machine with an old
compiler is irrelevant. This question is broader than that.

Either:

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.

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.

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.

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).

Thoughts ?

Mathieu


>
> Paolo
>

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