lkml.org 
[lkml]   [2020]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Control Dependencies vs C Compilers
    Date
    * Peter Zijlstra:

    > Our Documentation/memory-barriers.txt has a Control Dependencies section
    > (which I shall not replicate here for brevity) which lists a number of
    > caveats. But in general the work-around we use is:
    >
    > x = READ_ONCE(*foo);
    > if (x > 42)
    > WRITE_ONCE(*bar, 1);
    >
    > Where READ/WRITE_ONCE() cast the variable volatile. The volatile
    > qualifier dissuades the compiler from assuming it knows things and we
    > then hope it will indeed emit the branch like we'd expect.
    >
    >
    > Now, hoping the compiler generates correct code is clearly not ideal and
    > very dangerous indeed. Which is why my question to the compiler folks
    > assembled here is:
    >
    > Can we get a C language extention for this?

    For what exactly?

    Do you want a compiler that never simplifies conditional expressions
    (like some people want compilers that never re-associate floating point
    operations)?

    With a bit of effort, we could prototype such a compiler and run
    benchmarks against a kernel that was built using it. But I'm not sure
    if that's a good use of resources.

    > And while we have a fair number (and growing) existing users of this in
    > the kernel, I'd not be adverse to having to annotate them.

    But not using READ_ONCE and WRITE_ONCE?

    I think in GCC, they are called __atomic_load_n(foo, __ATOMIC_RELAXED)
    and __atomic_store_n(foo, __ATOMIC_RELAXED). GCC can't optimize relaxed
    MO loads and stores because the C memory model is defective and does not
    actually guarantee the absence of out-of-thin-air values (a property it
    was supposed to have). Obviously, actual implementations want to
    provide this guarantee. So it's really impossible right now to argue
    about this in any formal way and determine the validity of optimizations
    (which is why there are none, hopefully).

    In standard C, there is <stdatomic.h>, but its relaxed MO loads and
    stores can of course be optimized, so you'll need a compiler extension
    here.

    A different way of annotating this would be a variant of _Atomic where
    plain accesses have relaxed MO, not seq-cst MO.

    Thanks,
    Florian
    --
    Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
    Commercial register: Amtsgericht Muenchen, HRB 153243,
    Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

    \
     
     \ /
      Last update: 2020-10-06 23:21    [W:2.888 / U:0.168 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site