paul@419 | 1 | Low-Level Instructions and Macro Instructions
|
paul@419 | 2 | =============================================
|
paul@419 | 3 |
|
paul@450 | 4 | Instructions manipulated through the temporary infrastructure are reused and can be
|
paul@450 | 5 | corrupted by set_source and set_target operations. It might be better if such operations
|
paul@450 | 6 | cloned the instructions or if new instructions were explicitly created.
|
paul@450 | 7 |
|
paul@429 | 8 | Have contexts and values stored separately in memory. This involves eliminating DataValue
|
paul@429 | 9 | and storing attributes using two words.
|
paul@429 | 10 |
|
paul@419 | 11 | Migrate macro instructions such as the *Index instructions to library code implemented
|
paul@419 | 12 | using low-level instructions.
|
paul@419 | 13 |
|
paul@419 | 14 | Consider introducing classic machine level instructions (word addition, subtraction, and
|
paul@419 | 15 | so on) in order to implement all current RSVP instructions.
|
paul@419 | 16 |
|
paul@450 | 17 | Move common code sequences to a library routine, such as the context checking that occurs
|
paul@450 | 18 | in functions and methods.
|
paul@450 | 19 |
|
paul@450 | 20 | Return Value Optimisations
|
paul@450 | 21 | ==========================
|
paul@450 | 22 |
|
paul@450 | 23 | Attempt to use result data directly instead of transferring it explicitly to the working
|
paul@450 | 24 | registers and then using it.
|
paul@450 | 25 |
|
paul@450 | 26 | Perhaps store resultant working values on Block instances in order to better track active
|
paul@450 | 27 | values.
|
paul@450 | 28 |
|
paul@417 | 29 | Class and Module Attribute Assignment
|
paul@417 | 30 | =====================================
|
paul@417 | 31 |
|
paul@417 | 32 | Verify that the context information is correctly set, particularly for the unoptimised
|
paul@417 | 33 | cases.
|
paul@417 | 34 |
|
paul@417 | 35 | Update docs/assignment.txt.
|
paul@417 | 36 |
|
paul@431 | 37 | Prevent assignments within classes, such as method aliasing, from causing the source of an
|
paul@431 | 38 | assignment from being automatically generated. Instead, only external references should be
|
paul@431 | 39 | registered.
|
paul@431 | 40 |
|
paul@431 | 41 | Prevent "from <module> import ..." statements from registering references to such local
|
paul@431 | 42 | aliases such that they cause the source of each alias to be automatically generated.
|
paul@431 | 43 |
|
paul@419 | 44 | Consider attribute assignment observations, along with the possibility of class and module
|
paul@419 | 45 | attribute assignment.
|
paul@419 | 46 |
|
paul@419 | 47 | (Note direct assignments as usual, indirect assignments via the attribute usage
|
paul@419 | 48 | mechanism. During attribute collection and inference, add assigned values to all
|
paul@419 | 49 | inferred targets.)
|
paul@419 | 50 |
|
paul@419 | 51 | (Since class attributes can be assigned, StoreAttrIndex would no longer need to reject
|
paul@419 | 52 | static attributes, although this might still be necessary where attribute usage analysis
|
paul@419 | 53 | has not been performed.)
|
paul@419 | 54 |
|
paul@419 | 55 | Potentially consider changing static attribute details to use object-relative offsets in
|
paul@419 | 56 | order to simplify the instruction implementations. This might allow us to eliminate the
|
paul@419 | 57 | static attribute flag for attributes in the object table, at least at run-time.
|
paul@419 | 58 |
|
paul@413 | 59 | Dynamic Attribute Access
|
paul@413 | 60 | ========================
|
paul@413 | 61 |
|
paul@425 | 62 | Consider explicit accessor initialisation:
|
paul@425 | 63 |
|
paul@425 | 64 | attr = accessor("attr")
|
paul@425 | 65 | getattr(C, attr)
|
paul@413 | 66 |
|
paul@394 | 67 | Attribute Usage
|
paul@394 | 68 | ===============
|
paul@394 | 69 |
|
paul@445 | 70 | Loop entry points and other places where usage becomes more specific might be used as
|
paul@445 | 71 | places to impose guards. See tests/attribute_access_type_restriction_loop_list.py for an
|
paul@445 | 72 | example.
|
paul@445 | 73 |
|
paul@372 | 74 | Consider attribute usage observations being suspended inside blocks where AttributeError
|
paul@372 | 75 | may be caught (although this doesn't anticipate such exceptions being caught outside a
|
paul@372 | 76 | function altogether).
|
paul@372 | 77 |
|
paul@364 | 78 | Consider type deduction and its consequences where types belong to the same hierarchy
|
paul@364 | 79 | and where a guard could be generated for the most general type.
|
paul@364 | 80 |
|
paul@364 | 81 | Consider permitting multiple class alternatives where the attributes are all identical.
|
paul@364 | 82 |
|
paul@360 | 83 | Support class attribute positioning similar to instance attribute positioning, potentially
|
paul@360 | 84 | (for both) based on usage observations. For example, if __iter__ is used on two classes,
|
paul@360 | 85 | the class attribute could be exposed at a similar relative position to the class (and
|
paul@360 | 86 | potentially accessible using a LoadAttr-style instruction).
|
paul@360 | 87 |
|
paul@394 | 88 | **** Constant attribute users need not maintain usage since they are already resolved. ****
|
paul@394 | 89 |
|
paul@394 | 90 | Consider handling CallFunc in micropython.inspect in order to produce instances of specific classes.
|
paul@394 | 91 | Then, consider adding support for guard removal/verification where known instances are involved.
|
paul@394 | 92 | Consider handling branches of values within namespaces in order to support more precise value usage.
|
paul@394 | 93 |
|
paul@394 | 94 | Frame Optimisations
|
paul@394 | 95 | ===================
|
paul@394 | 96 |
|
paul@394 | 97 | Stack frame replacement where a local frame is unused after a call, such as in a tail call
|
paul@394 | 98 | situation.
|
paul@394 | 99 |
|
paul@394 | 100 | Local assignment detection plus frame re-use. Example: slice.__init__ calls
|
paul@394 | 101 | xrange.__init__ with the same arguments which are unchanged in xrange.__init__. There is
|
paul@419 | 102 | therefore no need to build a new frame for this call, although in some cases the locals
|
paul@419 | 103 | frame might need expanding.
|
paul@419 | 104 |
|
paul@419 | 105 | Inlining
|
paul@419 | 106 | ========
|
paul@419 | 107 |
|
paul@419 | 108 | Where a function or method call can always be determined, the body of the target could be
|
paul@419 | 109 | inlined - copied into place - within the caller. If the target is only ever called by a
|
paul@419 | 110 | single caller it could be moved into place.
|
paul@394 | 111 |
|
paul@394 | 112 | Function Specialisation
|
paul@394 | 113 | =======================
|
paul@394 | 114 |
|
paul@394 | 115 | Specialisation of certain functions, such as isinstance(x, cls) where cls is a known
|
paul@394 | 116 | constant.
|
paul@394 | 117 |
|
paul@394 | 118 | Structure and Object Table Optimisations
|
paul@394 | 119 | ========================================
|
paul@394 | 120 |
|
paul@394 | 121 | Fix object table entries for attributes not provided by any known object, or provide an
|
paul@394 | 122 | error, potentially overridden by options. For example, the augmented assignment methods
|
paul@394 | 123 | are not supported by the built-in objects and thus the operator module functions cause
|
paul@394 | 124 | the compilation to fail. Alternatively, just supply the methods since something has to do
|
paul@394 | 125 | so in the builtins.
|
paul@394 | 126 |
|
paul@394 | 127 | Consider attribute merging where many attributes are just aliases for the same underlying
|
paul@394 | 128 | definition.
|
paul@394 | 129 |
|
paul@349 | 130 | Consider references to defaults as occurring only within the context of a particular
|
paul@349 | 131 | function, thus eliminating default value classes if such functions are not themselves
|
paul@349 | 132 | invoked.
|
paul@349 | 133 |
|
paul@394 | 134 | Scope Handling
|
paul@394 | 135 | ==============
|
paul@394 | 136 |
|
paul@394 | 137 | Consider merging the InspectedModule.store tests with the scope conflict handling.
|
paul@394 | 138 |
|
paul@343 | 139 | Consider labelling _scope on assignments and dealing with the assignment of removed
|
paul@343 | 140 | attributes, possibly removing the entire assignment, and distinguishing between such cases
|
paul@343 | 141 | and unknown names.
|
paul@343 | 142 |
|
paul@342 | 143 | Check name origin where multiple branches could yield multiple scope interpretations:
|
paul@342 | 144 |
|
paul@342 | 145 | ----
|
paul@342 | 146 | try:
|
paul@342 | 147 | set # built-in name
|
paul@342 | 148 | except NameError:
|
paul@342 | 149 | from sets import Set as set # local definition of name
|
paul@342 | 150 |
|
paul@342 | 151 | set # could be confused by the local definition at run-time
|
paul@342 | 152 | ----
|
paul@342 | 153 |
|
paul@394 | 154 | Object Coverage
|
paul@394 | 155 | ===============
|
paul@394 | 156 |
|
paul@332 | 157 | Support __init__ traversal (and other implicit names) more effectively.
|
paul@332 | 158 |
|
paul@394 | 159 | Other
|
paul@394 | 160 | =====
|
paul@394 | 161 |
|
paul@449 | 162 | Support self attribute visualisation in the reports and/or provide a function or
|
paul@449 | 163 | annotations which can provide the eventual optimisation directly to such components.
|
paul@408 | 164 |
|
paul@332 | 165 | Check context_value initialisation (avoiding or handling None effectively).
|
paul@332 | 166 |
|
paul@342 | 167 | Consider better "macro" support where new expressions need to be generated and processed.
|
paul@402 | 168 |
|
paul@402 | 169 | Detect TestIdentity results involving constants, potentially optimising status-affected
|
paul@402 | 170 | instructions:
|
paul@402 | 171 |
|
paul@402 | 172 | TestIdentity(x, y) # where x is always y
|
paul@402 | 173 | JumpIfFalse(...) # would be removed (never false)
|
paul@402 | 174 | JumpIfTrue(...) # changed to Jump(...)
|
paul@402 | 175 |
|
paul@402 | 176 | Status-affected blocks could be optimised away for such constant-related results.
|