"allow-store-data-races" #23
MasterInQuestion
started this conversation in
GCC
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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).
Beta Was this translation helpful? Give feedback.
All reactions