lkml.org 
[lkml]   [2021]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] LKMM: Add volatile_if()
    On Fri, Jun 04, 2021 at 11:43:59AM +0100, Will Deacon wrote:
    > On Fri, Jun 04, 2021 at 12:12:07PM +0200, Peter Zijlstra wrote:
    > > With optimizing compilers becoming more and more agressive and C so far
    > > refusing to acknowledge the concept of control-dependencies even while
    > > we keep growing the amount of reliance on them, things will eventually
    > > come apart.
    > >
    > > There have been talks with toolchain people on how to resolve this; one
    > > suggestion was allowing the volatile qualifier on branch statements like
    > > 'if', but so far no actual compiler has made any progress on this.
    > >
    > > Rather than waiting any longer, provide our own construct based on that
    > > suggestion. The idea is by Alan Stern and refined by Paul and myself.
    > >
    > > Code generation is sub-optimal (for the weak architectures) since we're
    > > forced to convert the condition into another and use a fixed conditional
    > > branch instruction, but shouldn't be too bad.
    > >
    > > Usage of volatile_if requires the @cond to be headed by a volatile load
    > > (READ_ONCE() / atomic_read() etc..) such that the compiler is forced to
    > > emit the load and the branch emitted will have the required
    > > data-dependency. Furthermore, volatile_if() is a compiler barrier, which
    > > should prohibit the compiler from lifting anything out of the selection
    > > statement.
    >
    > When building with LTO on arm64, we already upgrade READ_ONCE() to an RCpc
    > acquire. In this case, it would be really good to avoid having the dummy
    > conditional branch somehow, but I can't see a good way to achieve that.

    Thinking more on this, an alternative angle would be having READ_ONCE_CTRL()
    instead of volatile_if. That would then expand (on arm64) to either
    something like:

    LDR X0, [X1]
    CBNZ X0, 1f // Dummy ctrl
    1:

    or, with LTO:

    LDAPR X0, [X1] // RCpc

    and we'd avoid the redundancy.

    Will

    \
     
     \ /
      Last update: 2021-06-04 13:13    [W:4.134 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site