lkml.org 
[lkml]   [2014]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/5] arch: atomic rework
    > I don't know the specifics of your example, but from how I understand
    > it, I don't see a problem if the compiler can prove that the store will
    > always happen.
    >
    > To be more specific, if the compiler can prove that the store will
    > happen anyway, and the region of code can be assumed to always run
    > atomically (e.g., there's no loop or such in there), then it is known
    > that we have one atomic region of code that will always perform the
    > store, so we might as well do the stuff in the region in some order.
    >
    > Now, if any of the memory accesses are atomic, then the whole region of
    > code containing those accesses is often not atomic because other threads
    > might observe intermediate results in a data-race-free way.
    >
    > (I know that this isn't a very precise formulation, but I hope it brings
    > my line of reasoning across.)

    So given something like:

    if (x)
    y = 3;

    assuming both x and y are atomic (so don't gimme crap for now knowing
    the C11 atomic incantations); and you can prove x is always true; you
    don't see a problem with not emitting the conditional?

    Avoiding the conditional changes the result; see that control dependency
    email from earlier. In the above example the load of X and the store to
    Y are strictly ordered, due to control dependencies. Not emitting the
    condition and maybe not even emitting the load completely wrecks this.

    Its therefore an invalid optimization to take out the conditional or
    speculate the store, since it takes out the dependency.


    \
     
     \ /
      Last update: 2014-02-12 12:21    [W:4.149 / U:0.208 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site