diff options
Diffstat (limited to 'src/pass.h')
| -rw-r--r-- | src/pass.h | 30 |
1 files changed, 30 insertions, 0 deletions
diff --git a/src/pass.h b/src/pass.h index 0be45e2d1..08237b271 100644 --- a/src/pass.h +++ b/src/pass.h @@ -99,6 +99,36 @@ struct PassOptions { InliningOptions inlining; // Optimize assuming things like div by 0, bad load/store, will not trap. bool ignoreImplicitTraps = false; + // Optimize assuming a trap will never happen at runtime. This is similar to + // ignoreImplicitTraps, but different: + // + // * ignoreImplicitTraps simply ignores the side effect of trapping when it + // computes side effects, and then passes work with that data. + // * trapsNeverHappen assumes that if an instruction with a possible trap is + // reached, then it does not trap, and an (unreachable) - that always + // traps - is never reached. + // + // The main difference is that in trapsNeverHappen mode we will not move + // around code that might trap, like this: + // + // (if (condition) (code)) + // + // If (code) might trap, ignoreImplicitTraps ignores that trap, and it might + // end up moving (code) to happen before the (condition), that is, + // unconditionally. trapsNeverHappen, on the other hand, does not ignore the + // side effect of the trap; instead, it will potentially remove the trapping + // instruction, if it can - it is always safe to remove a trap in this mode, + // as the traps are assumed to not happen. Where it cannot remove the side + // effect, it will at least not move code around. + // + // A consequence of this difference is that code that puts a possible trap + // behind a condition is unsafe in ignoreImplicitTraps, but safe in + // trapsNeverHappen. In general, trapsNeverHappen is safe on production code + // where traps are either fatal errors or assertions, and it is assumed + // neither of those can happen (and it is undefined behavior if they do). + // + // TODO: deprecate and remove ignoreImplicitTraps. + bool trapsNeverHappen = false; // Optimize assuming that the low 1K of memory is not valid memory for the // application to use. In that case, we can optimize load/store offsets in // many cases. |