diff options
Diffstat (limited to 'src/ir/properties.h')
| -rw-r--r-- | src/ir/properties.h | 45 |
1 files changed, 45 insertions, 0 deletions
diff --git a/src/ir/properties.h b/src/ir/properties.h index d477cb11c..4909dfbc8 100644 --- a/src/ir/properties.h +++ b/src/ir/properties.h @@ -335,6 +335,51 @@ inline bool canEmitSelectWithArms(Expression* ifTrue, Expression* ifFalse) { return ifTrue->type.isSingle() && ifFalse->type.isSingle(); } +// An intrinsically-nondeterministic expression is one that can return different +// results for the same inputs, and that difference is *not* explained by +// other expressions that interact with this one. Hence the cause of +// nondeterminism can be said to be "intrinsic" - it is internal and inherent in +// the expression. +// +// To see the issue more concretely, consider these: +// +// x = load(100); +// .. +// y = load(100); +// +// versus +// +// x = struct.new(); +// .. +// y = struct.new(); +// +// Are x and y identical in both cases? For loads, we can look at the code +// in ".." to see: if there are no possible stores to memory, then the +// result is identical (and we have EffectAnalyzer for that). For the GC +// allocations, though, it doesn't matter what is in "..": there is nothing +// in the wasm that we can check to find out if the results are the same or +// not. (In fact, in this case they are always not the same.) So the +// nondeterminism is "intrinsic." +// +// Thus, loads are nondeterministic but not intrinsically so, while GC +// allocations are actual examples of intrinsically nondeterministic +// instructions. If wasm were to add "get current time" or "get a random number" +// instructions then those would also be intrinsically nondeterministic. +// +// * Note that NaN nondeterminism is ignored here. Technically that allows e.g. +// an f32.add to be nondeterministic, but it is a valid wasm implementation +// to have deterministic NaN behavior, and we optimize under that assumption. +// So NaN nondeterminism does not cause anything to be intrinsically +// nondeterministic. +// * Note that calls are ignored here. In theory this concept could be defined +// either way for them (that is, we could potentially define them as either +// intrinsically nondeterministic, or not, and each could make sense in its +// own way). It is simpler to ignore them here, which means we only consider +// the behavior of the expression provided here (including its chldren), and +// not external code. +// +bool isIntrinsicallyNondeterministic(Expression* curr, FeatureSet features); + } // namespace Properties } // namespace wasm |