aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorchriseth <chris@ethereum.org>2017-12-11 23:10:40 +0800
committerchriseth <chris@ethereum.org>2017-12-11 23:12:08 +0800
commit2add4f604b86c67da9f9b1616f2374b67f755878 (patch)
tree70e6e5aa1072ba815491d4440fe9574de8e397d0
parenteebeb52aed6edb3896137f796aca344eb831cafc (diff)
downloaddexon-solidity-2add4f604b86c67da9f9b1616f2374b67f755878.tar
dexon-solidity-2add4f604b86c67da9f9b1616f2374b67f755878.tar.gz
dexon-solidity-2add4f604b86c67da9f9b1616f2374b67f755878.tar.bz2
dexon-solidity-2add4f604b86c67da9f9b1616f2374b67f755878.tar.lz
dexon-solidity-2add4f604b86c67da9f9b1616f2374b67f755878.tar.xz
dexon-solidity-2add4f604b86c67da9f9b1616f2374b67f755878.tar.zst
dexon-solidity-2add4f604b86c67da9f9b1616f2374b67f755878.zip
Description of the optimiser and stages.
-rw-r--r--libjulia/optimiser/README.md61
1 files changed, 61 insertions, 0 deletions
diff --git a/libjulia/optimiser/README.md b/libjulia/optimiser/README.md
new file mode 100644
index 00000000..771cb707
--- /dev/null
+++ b/libjulia/optimiser/README.md
@@ -0,0 +1,61 @@
+## IULIA Optimiser
+
+The iulia optimiser consists of several stages and components that all transform
+the AST in a semantically equivalent way. The goal is to end up either with code
+that is shorter or at least only marginally longer but will allow further
+optimisation steps.
+
+The optimiser currently follows a purely greedy strategy and does not do any
+backtracking.
+
+## Disambiguator
+
+The disambiguator takes an AST and returns a fresh copy where all identifiers have
+names unique to the input AST. This is a prerequisite for all other optimiser stages.
+One of the benefits is that identifier lookup does not need to take scopes into account
+and we can basically ignore the result of the analysis phase.
+
+All subsequent stages have the property that all names stay unique. This means if
+a new identifier needs to be introduced, a new unique name is generated.
+
+## Function Hoister
+
+The function hoister moves all function definitions to the topmost block. This is
+a semantically equivalent transformation as long as it is performed after the
+disambiguation stage. The reason is that moving a definition upwards cannot decrease
+its visibility and it is impossible to reference variables defined in a different function.
+
+The benefit of this stage is that function definitions can be lookup up more easily.
+
+## Function Grouper
+
+The function grouper has to be applied after the disambiguator and the function hoister.
+Its effect is that all topmost elements that are not function definitions are moved
+into a single block which is the first satement of the root block.
+
+After this step, a program has the following normal form:
+
+ { I F... }
+
+Where I is a block that does not contain any function definitions (not even recursively)
+and F is a list of function definitions such that no function contains a function definition.
+
+## Functional Inliner
+
+The functional inliner depends on the disambiguator, the function hoister and function grouper.
+It performs function inlining such that the result of the inlining is an expression. This can
+only be done if the body of the function to be inlined has the form ``{ r := E }`` where ``r``
+is the single return value of the function, ``E`` is an expression and all arguments in the
+function call are so-called movable expressions. A movable expression is either a literal, a
+variable or a function call (or EVM opcode) which does not have side-effects and also does not
+depend on any side-effects.
+
+As an example, neither ``mload`` nor ``mstore`` would be allowed.
+
+## Full Function Inliner
+
+## Variable Eliminator
+
+## Unused Declaration Pruner
+
+## Function Unifier