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