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 Allow unrestricted class and module assignment (but not new external binding of
30 attributes), eliminating run-time checks on object types in instructions like
31 StoreAttrIndex. This may involve less specific objects being identified during inspection.
32
33 Verify that the context information is correctly set, particularly for the unoptimised
34 cases.
35
36 Update docs/assignment.txt.
37
38 Prevent assignments within classes, such as method aliasing, from causing the source of an
39 assignment from being automatically generated. Instead, only external references should be
40 registered.
41
42 Prevent "from <module> import ..." statements from registering references to such local
43 aliases such that they cause the source of each alias to be automatically generated.
44
45 Consider attribute assignment observations, along with the possibility of class and module
46 attribute assignment.
47
48 (Note direct assignments as usual, indirect assignments via the attribute usage
49 mechanism. During attribute collection and inference, add assigned values to all
50 inferred targets.)
51
52 (Since class attributes can be assigned, StoreAttrIndex would no longer need to reject
53 static attributes, although this might still be necessary where attribute usage analysis
54 has not been performed.)
55
56 Potentially consider changing static attribute details to use object-relative offsets in
57 order to simplify the instruction implementations. This might allow us to eliminate the
58 static attribute flag for attributes in the object table, at least at run-time.
59
60 Dynamic Attribute Access
61 ========================
62
63 Consider explicit accessor initialisation:
64
65 attr = accessor("attr")
66 getattr(C, attr)
67
68 Attribute Usage
69 ===============
70
71 To consider: is it useful to distinguish between attribute name sets when the same names
72 are mentioned, but where one path through the code sets different values on attributes
73 than another? The _attrtypes collapses observations in order to make a list of object
74 types for a name, and the final set of names leading to such type deductions might be a
75 useful annotation to be added alongside _attrcombined.
76
77 Interface/Type Generalisation
78 -----------------------------
79
80 Consolidate interface observations by taking all cached table accesses and determining
81 which usage patterns lead to the same types. For example, if full usage of {a, b} and
82 {a, b, c} leads to A and B in both cases, either {a, b} can be considered as partial usage
83 of the complete interface {a, b, c}, or the latter can be considered as an
84 overspecification of the former.
85
86 Consider type deduction and its consequences where types belong to the same hierarchy
87 and where a guard could be generated for the most general type.
88
89 Consider permitting multiple class alternatives where the attributes are all identical.
90
91 Support class attribute positioning similar to instance attribute positioning, potentially
92 (for both) based on usage observations. For example, if __iter__ is used on two classes,
93 the class attribute could be exposed at a similar relative position to the class (and
94 potentially accessible using a LoadAttr-style instruction).
95
96 **** Constant attribute users need not maintain usage since they are already resolved. ****
97
98 Self-related Usage
99 ------------------
100
101 Perform attribute usage on attributes of self as names, potentially combining observations
102 across methods.
103
104 Additional Guards
105 -----------------
106
107 Consider handling branches of values within namespaces in order to support more precise value usage.
108
109 Loop entry points and other places where usage becomes more specific might be used as
110 places to impose guards. See tests/attribute_access_type_restriction_loop_list.py for an
111 example. (Such information is already shown in the reports.)
112
113 Strict Interfaces/Types
114 -----------------------
115
116 Make the gathering of usage parameterisable according to the optimisation level so that a
117 choice can be made between control-flow-dependent observations and the simple collection
118 of all attributes used with a name (producing a more static interface observation).
119
120 AttributeError
121 --------------
122
123 Consider attribute usage observations being suspended or optional inside blocks where
124 AttributeError may be caught (although this doesn't anticipate such exceptions being
125 caught outside a function altogether). For example:
126
127 y = a.y
128 try:
129 z = a.z # z is an optional attribute
130 except AttributeError:
131 z = None
132
133 Instantiation Deduction
134 -----------------------
135
136 Consider handling CallFunc in micropython.inspect in order to produce instances of specific classes.
137 Then, consider adding support for guard removal/verification where known instances are involved. For
138 example:
139
140 l = []
141 l.append(123) # type deductions are filtered using instantiation knowledge
142
143 Frame Optimisations
144 ===================
145
146 Stack frame replacement where a local frame is unused after a call, such as in a tail call
147 situation.
148
149 Local assignment detection plus frame re-use. Example: slice.__init__ calls
150 xrange.__init__ with the same arguments which are unchanged in xrange.__init__. There is
151 therefore no need to build a new frame for this call, although in some cases the locals
152 frame might need expanding.
153
154 Reference tracking where objects associated with names are assigned to attributes of other
155 objects may assist in allocation optimisations. Recording whether an object referenced by
156 a name is assigned to an attribute, propagated to another name and assigned to an
157 attribute, or passed to another function or method might, if such observations were
158 combined, allow frame-based or temporary allocation to occur.
159
160 Instantiation
161 =============
162
163 Specific instances could be produced, providing type information and acting somewhat like
164 classes during inspection.
165
166 Inlining
167 ========
168
169 Where a function or method call can always be determined, the body of the target could be
170 inlined - copied into place - within the caller. If the target is only ever called by a
171 single caller it could be moved into place. This could enhance deductions based on
172 attribute usage since observations from the inlined function would be merged into the
173 caller.
174
175 Function Specialisation
176 =======================
177
178 Specialisation of certain functions, such as isinstance(x, cls) where cls is a known
179 constant.
180
181 Structure and Object Table Optimisations
182 ========================================
183
184 Fix object table entries for attributes not provided by any known object, or provide an
185 error, potentially overridden by options. For example, the augmented assignment methods
186 are not supported by the built-in objects and thus the operator module functions cause
187 the compilation to fail. Alternatively, just supply the methods since something has to do
188 so in the builtins.
189
190 Consider attribute merging where many attributes are just aliases for the same underlying
191 definition.
192
193 Consider references to defaults as occurring only within the context of a particular
194 function, thus eliminating default value classes if such functions are not themselves
195 invoked.
196
197 Scope Handling
198 ==============
199
200 Consider merging the InspectedModule.store tests with the scope conflict handling.
201
202 Consider labelling _scope on assignments and dealing with the assignment of removed
203 attributes, possibly removing the entire assignment, and distinguishing between such cases
204 and unknown names.
205
206 Check name origin where multiple branches could yield multiple scope interpretations:
207
208 try:
209 set # built-in name
210 except NameError:
211 from sets import Set as set # local definition of name
212
213 set # could be confused by the local definition at run-time
214
215 Object Coverage
216 ===============
217
218 Support __init__ traversal (and other implicit names) more effectively.
219
220 Importing Modules
221 =================
222
223 Consider supporting relative imports, even though this is arguably a misfeature.
224
225 Other
226 =====
227
228 Consider a separate annotation phase where deductions are added to the AST for the
229 benefit of both the reporting and code generation phases.
230
231 Support self attribute visualisation in the reports and/or provide a function or
232 annotations which can provide the eventual optimisation directly to such components.
233
234 Check context_value initialisation (avoiding or handling None effectively).
235
236 Consider better "macro" support where new expressions need to be generated and processed.
237
238 Detect TestIdentity results involving constants, potentially optimising status-affected
239 instructions:
240
241 TestIdentity(x, y) # where x is always y
242 JumpIfFalse(...) # would be removed (never false)
243 JumpIfTrue(...) # changed to Jump(...)
244
245 Status-affected blocks could be optimised away for such constant-related results.
