Wasmtime GitHub notifications bot (Nov 11 2020 at 19:31): Wasmtime GitHub notifications bot (Nov 11 2020 at 19:31):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.
Wasmtime GitHub notifications bot (Nov 11 2020 at 19:39):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?
Wasmtime GitHub notifications bot (Nov 11 2020 at 19:58):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.
Wasmtime GitHub notifications bot (Nov 11 2020 at 19:59):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_racememory flag to enable this optimization.
Wasmtime GitHub notifications bot (Nov 12 2020 at 06:13):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: Nov 22 2024 at 17:03 UTC