bjorn3 commented on Issue #2389:
In particular, we need to ensure
that the use is the only use (otherwise the load happens more than
once)If there are no atomic accesses in between, no effectful operations and no stores, then duplicating loads should be fine I think.
cfallin commented on Issue #2389:
In particular, we need to ensure
that the use is the only use (otherwise the load happens more than
once)If there are no atomic accesses in between, no effectful operations and no stores, then duplicating loads should be fine I think.
I thought so too at first, but the interesting case occurs once we have threads/shared memory -- if a store to a particular address interleaves between two loads L1 and L2, which are two instances originating from the same CLIF-level load L, then L1 and L2 could produce different values, which could result in impossible executions.
I think that some compilers may reason that such a case is undefined according to the memory consistency model, so anything can happen, but I'm a little uncomfortable allowing for this from a security / risk-mitigation perspective. Thoughts?
bjorn3 commented on Issue #2389:
if a store to a particular address interleaves between two loads L1 and L2, which are two instances originating from the same CLIF-level load L, then L1 and L2 could produce different values, which could result in impossible executions.
That's why there must not be an atomic operation, nor instruction with side-effects. If neither exists in between, it is guaranteed that there is no synchronization between the current thread and another and as such multiple non-atomic memory accesses to the same location would consistute a data-race, which is UB.
bjorn3 commented on Issue #2389:
I think that some compilers may reason that such a case is undefined according to the memory consistency model, so anything can happen, but I'm a little uncomfortable allowing for this from a security / risk-mitigation perspective. Thoughts?
There could be a new
no_race
memory flag to enable this optimization.
julian-seward1 commented on Issue #2389:
@cfallin +1 for not allowing loads to be duplicated. We might be able to construct some complex story about why this is OK, but it's extra verification/reasoning-overhead/fragility that we don't want to carry if we don't have to. Besides, loads are expensive and generally a hindrance to ILP.
Last updated: Dec 23 2024 at 12:05 UTC