"allow-store-data-races"

[MasterInQuestion]

    Continues:
    Improve documentation of "-fallow-store-data-races"
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309#c4
    (no account there)
    @jwakely

    For reference:
    https://lore.kernel.org/lkml/[email protected]/T/#m8f26126a1db18ad4335151ce1d80c3616cf8d7e9
    .
    Recommendation is don't use with multi-threading. (until better implementation)

    “... include hoisting (loop unrolling) or if-conversions (to speculative execution) that may cause existing values early overwritten and rewritten back later.
    Such re-writing is safe for single-threading, but unsafe for multi-threading.
    Note on some processors (and for certain programs), ~~if-conversions~~ this option may be required to enable vectorization (instruction-level parallelism).”
    .
    Likely because the related optimization logic not well defined.
    Pretty much software-implemented speculative execution yet only suitable for single-threading.

    “If there are non-atomic (concurrent/parallel) accesses to a variable: we can already assume it's not ~~concurrently~~ sequentially accessed.
    Because any such potentially conflicting action would already be a data race and UB (Undefined Behavior).”
<^>    Not necessarily when properly implemented. And the because has broken logic connection.
    Speculative execution itself exploits the similar data race: pre-computing the possible outcomes and use only the needed.

    Dependency on certain yet to be determined values doesn't really stall the operation:
    When there's ample computing power, and speed is preferred over eco-efficiency.

    "allow-store-data-races", perhaps the name is misleading:
    This "data-races" should not be the typical data race (determination of "${Var}" undeterministic).