aboutsummaryrefslogtreecommitdiffstats
path: root/libjulia/optimiser/README.md
diff options
context:
space:
mode:
authorchriseth <chris@ethereum.org>2018-10-02 00:27:07 +0800
committerchriseth <chris@ethereum.org>2018-10-12 21:19:29 +0800
commitd60a2511fdc625928b5a2ee449e39ba78a3d1296 (patch)
treea885022f3f4d0c89608f161a10d8d668a8fc7e89 /libjulia/optimiser/README.md
parent1d312c8e4073e2e7ce9a23a721013942e1e5c727 (diff)
downloaddexon-solidity-d60a2511fdc625928b5a2ee449e39ba78a3d1296.tar.gz
dexon-solidity-d60a2511fdc625928b5a2ee449e39ba78a3d1296.tar.zst
dexon-solidity-d60a2511fdc625928b5a2ee449e39ba78a3d1296.zip
Expression joiner.
Diffstat (limited to 'libjulia/optimiser/README.md')
-rw-r--r--libjulia/optimiser/README.md41
1 files changed, 41 insertions, 0 deletions
diff --git a/libjulia/optimiser/README.md b/libjulia/optimiser/README.md
index 877f8255..4a50d5ca 100644
--- a/libjulia/optimiser/README.md
+++ b/libjulia/optimiser/README.md
@@ -56,6 +56,47 @@ depend on any side-effects.
As an example, neither ``mload`` nor ``mstore`` would be allowed.
+## Expression Splitter
+
+The expression splitter turns expressions like ``add(mload(x), mul(mload(y), 0x20))``
+into a sequence of declarations of unique variables that are assigned sub-expressions
+of that expression so that each function call has only variables or literals
+as arguments.
+
+The above would be transformed into
+
+ {
+ let _1 := mload(y)
+ let _2 := mul(_1, 0x20)
+ let _3 := mload(x)
+ let z := add(_3, _2)
+ }
+
+Note that this transformation does not change the order of opcodes or function calls.
+
+It is not applied to loop conditions, because the loop control flow does not allow
+this "outlining" of the inner expressions in all cases.
+
+The final program should be in a form such that with the exception of loop conditions,
+function calls can only appear in the right-hand side of a variable declaration,
+assignments or expression statements and all arguments have to be constants or variables.
+
+The benefits of this form are that it is much easier to re-order the sequence of opcodes
+and it is also easier to perform function call inlining. The drawback is that
+such code is much harder to read for humans.
+
+## Expression Joiner
+
+This is the opposite operation of the expression splitter. It turns a sequence of
+variable declarations that have exactly one reference into a complex expression.
+This stage again fully preserves the order of function calls and opcode executions.
+It does not make use of any information concerning the commutability of opcodes;
+if moving the value of a variable to its place of use would change the order
+of any function call or opcode execution, the transformation is not performed.
+
+Note that the component will not move the assigned value of a variable assignment
+or a variable that is referenced more than once.
+
## Full Function Inliner
## Rematerialisation