1/*
2 * Copyright (C) 2015 Apple Inc. All rights reserved.
3 *
4 * Redistribution and use in source and binary forms, with or without
5 * modification, are permitted provided that the following conditions
6 * are met:
7 * 1. Redistributions of source code must retain the above copyright
8 * notice, this list of conditions and the following disclaimer.
9 * 2. Redistributions in binary form must reproduce the above copyright
10 * notice, this list of conditions and the following disclaimer in the
11 * documentation and/or other materials provided with the distribution.
12 *
13 * THIS SOFTWARE IS PROVIDED BY APPLE INC. ``AS IS'' AND ANY
14 * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
15 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
16 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE INC. OR
17 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
18 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
19 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
20 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
21 * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
22 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
23 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
24 */
25
26#pragma once
27
28#if ENABLE(DFG_JIT)
29
30namespace JSC { namespace DFG {
31
32class Graph;
33struct Node;
34
35// A conservative approximation of whether the node will perform the kind of effect that would prevent
36// subsequent nodes from exiting to this node's exit origin. Exiting after an effect to that effect's
37// exit origin would cause the effect to execute a second time. Two kinds of such effects can exist:
38//
39// Observable heap or stack effect: If we perform such an effect and then exit to the same origin, that
40// effect will be executed a second time, which is incorrect.
41//
42// OSR exit state update: This doesn't do any observable side-effect, but it tells OSR exit that it
43// should recover some value as if an effect had happened. For example, a MovHint will tell OSR exit
44// that some bytecode variable now has a new value. If we exit to the exit origin of a MovHint after we
45// "execute" the MovHint, then the bytecode state will look as if we had already executed that bytecode
46// instruction. This could cause issues for example for bytecode like:
47//
48// op_add r1, r1, r2
49//
50// which will get lowered to something like:
51//
52// a: ArithAdd(...)
53// b: MovHint(@a, r1)
54//
55// If we exit to the op_add after executing the MovHint, then r1 will already contain the result of the
56// add. Then after exit we'll do the add again, and r1 will have the wrong value. Because of object
57// allocation elimination and PutStack sinking, we can also have other OSR exit updates, like
58// KillStack, PutHint, among others. They don't do anything so long as we stay in optimized code, but
59// they tell OSR exit how to reconstitute state.
60
61bool clobbersExitState(Graph&, Node*);
62
63} } // namespace JSC::DFG
64
65#endif // ENABLE(DFG_JIT)
66