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 Uninitialised Attributes
6 ========================
7
8 Make sure that these are either detected or are initialised in a form that might cause an
9 exception. The latter mechanism might then support attribute deletion.
10
11 Low-Level Instructions and Macro Instructions
12 =============================================
13
14 Have contexts and values stored separately in memory. This involves eliminating DataValue
15 and storing attributes using two words.
16
17 Migrate macro instructions such as the *Index instructions to library code implemented
18 using low-level instructions.
19
20 Consider introducing classic machine level instructions (word addition, subtraction, and
21 so on) in order to implement all current RSVP instructions.
22
23 Move common code sequences to a library routine, such as the context checking that occurs
24 in functions and methods.
25
26 Dataflow Optimisations
27 ======================
28
29 Assignments, particularly now that no result register exists, may cause StoreTemp/LoadTemp
30 instruction pairs to be produced and these could be eliminated.
31
32 Ambiguous/Multiple Class/Function Definitions
33 =============================================
34
35 Classes and functions are not supposed to have multiple definitions, where one code path
36 may define one form of a class or function with a given name and another code path may
37 define another form with that name. Currently, such multiple definitions are treated like
38 "unions" in the object table.
39
40 Consider functions as well as classes which are supported using "shadow" names for the
41 second and subsequent definitions of classes in the same namespace.
42
43 Class and Module Attribute Assignment
44 =====================================
45
46 Allow unrestricted class and module assignment (but not new external binding of
47 attributes), eliminating run-time checks on object types in instructions like
48 StoreAttrIndex. This may involve less specific objects being identified during inspection.
49
50 Potentially re-evaluate class bases in order to see if they are non-constant.
51
52 Verify that the context information is correctly set, particularly for the unoptimised
53 cases.
54
55 Update docs/assignment.txt.
56
57 Prevent assignments within classes, such as method aliasing, from causing the source of an
58 assignment from being automatically generated. Instead, only external references should be
59 registered.
60
61 Prevent "from <module> import ..." statements from registering references to such local
62 aliases such that they cause the source of each alias to be automatically generated.
63
64 Consider attribute assignment observations, along with the possibility of class and module
65 attribute assignment.
66
67 (Note direct assignments as usual, indirect assignments via the attribute usage
68 mechanism. During attribute collection and inference, add assigned values to all
69 inferred targets.)
70
71 (Since class attributes can be assigned, StoreAttrIndex would no longer need to reject
72 static attributes, although this might still be necessary where attribute usage analysis
73 has not been performed.)
74
75 Potentially consider changing static attribute details to use object-relative offsets in
76 order to simplify the instruction implementations. This might allow us to eliminate the
77 static attribute flag for attributes in the object table, at least at run-time.
78
79 Dynamic Attribute Access
80 ========================
81
82 Consider explicit accessor initialisation:
83
84 attr = accessor("attr")
85 getattr(C, attr)
86
87 Attribute Usage
88 ===============
89
90 To consider: is it useful to distinguish between attribute name sets when the same names
91 are mentioned, but where one path through the code sets different values on attributes
92 than another? The _attrtypes collapses observations in order to make a list of object
93 types for a name, and the final set of names leading to such type deductions might be a
94 useful annotation to be added alongside _attrcombined.
95
96 (Update the reports to group identical sets of attribute names.)
97
98 Attribute usage on attributes might be possible if one can show that the expression of an
99 attribute access is constant and that the attribute target is also constant or only refers
100 to a single type. For example, in the sys module:
101
102 stderr = file()
103
104 If no work is done to associate the result of the invocation with the stderr name, then
105 one could instead at least attempt to determine whether stderr is assigned only once. If
106 so, it might be possible to record attribute usage on references to the name. For example:
107
108 sys.stderr.write(...) # sys.stderr supports write -> {file, ...}
109
110 Interface/Type Generalisation
111 -----------------------------
112
113 Consolidate interface observations by taking all cached table accesses and determining
114 which usage patterns lead to the same types. For example, if full usage of {a, b} and
115 {a, b, c} leads to A and B in both cases, either {a, b} can be considered as partial usage
116 of the complete interface {a, b, c}, or the latter can be considered as an
117 overspecification of the former.
118
119 Consider type deduction and its consequences where types belong to the same hierarchy
120 and where a guard could be generated for the most general type.
121
122 Consider permitting multiple class alternatives where the attributes are all identical.
123
124 Support class attribute positioning similar to instance attribute positioning, potentially
125 (for both) based on usage observations. For example, if __iter__ is used on two classes,
126 the class attribute could be exposed at a similar relative position to the class (and
127 potentially accessible using a LoadAttr-style instruction).
128
129 **** Constant attribute users need not maintain usage since they are already resolved. ****
130
131 Self-Related Usage
132 ------------------
133
134 Perform attribute usage on attributes of self as names, potentially combining observations
135 across methods.
136
137 Additional Guards
138 -----------------
139
140 Consider handling branches of values within namespaces in order to support more precise
141 value usage.
142
143 Loop entry points and other places where usage becomes more specific might be used as
144 places to impose guards. See tests/attribute_access_type_restriction_loop_list.py for an
145 example. (Such information is already shown in the reports.)
146
147 Strict Interfaces/Types
148 -----------------------
149
150 Make the gathering of usage parameterisable according to the optimisation level so that a
151 choice can be made between control-flow-dependent observations and the simple collection
152 of all attributes used with a name (producing a more static interface observation).
153
154 AttributeError
155 --------------
156
157 Consider attribute usage observations being suspended or optional inside blocks where
158 AttributeError may be caught (although this doesn't anticipate such exceptions being
159 caught outside a function altogether). For example:
160
161 y = a.y
162 try:
163 z = a.z # z is an optional attribute
164 except AttributeError:
165 z = None
166
167 Frame Optimisations
168 ===================
169
170 Stack frame replacement where a local frame is unused after a call, such as in a tail call
171 situation.
172
173 Local assignment detection plus frame re-use. Example: slice.__init__ calls
174 xrange.__init__ with the same arguments which are unchanged in xrange.__init__. There is
175 therefore no need to build a new frame for this call, although in some cases the locals
176 frame might need expanding.
177
178 Reference tracking where objects associated with names are assigned to attributes of other
179 objects may assist in allocation optimisations. Recording whether an object referenced by
180 a name is assigned to an attribute, propagated to another name and assigned to an
181 attribute, or passed to another function or method might, if such observations were
182 combined, allow frame-based or temporary allocation to occur.
183
184 Instantiation Deduction
185 =======================
186
187 Consider handling Const, List and Tuple in micropython.inspect in order to produce
188 instances of specific classes. Then, consider adding support for guard
189 removal/verification where known instances are involved. For example:
190
191 l = []
192 l.append(123) # type deductions are filtered using instantiation knowledge
193
194 Currently, this is done only for Const values in the context of attribute accesses during
195 inspection.
196
197 Handling CallFunc in a similar way is more challenging. Consider the definitions in the
198 sys module:
199
200 stderr = file()
201
202 It must first be established that file only ever refers to the built-in file class, and
203 only then can the assumption be made that stderr in this case refers to instances of file.
204 If file can also refer to other objects, potential filtering operations are more severely
205 limited.
206
207 Propagation of type information can also occur. For example:
208
209 DeducedSource(module, program).deduce()
210
211 The DeducedSource invocation, if yielding an instance of the DeducedSource class, can then
212 supply the attribute access operation with type information.
213
214 A more advanced example involves accesses then invocations:
215
216 x = self.__class__()
217
218 Here, the effect should be the inference that x may refer to an instance of one of a
219 number of eligible types of which self is also an instance.
220
221 Invocation-Related Deduction
222 ============================
223
224 Where an attribute access (either in conjunction with usage observations or independently)
225 could refer to a number of different targets, but where the resulting attribute is then
226 used in an invocation, filtering of the targets could be done to eliminate any targets
227 that are not callable. Guards would need introducing to prevent inappropriate operations
228 from occurring at run-time.
229
230 Inlining
231 ========
232
233 Where a function or method call can always be determined, the body of the target could be
234 inlined - copied into place - within the caller. If the target is only ever called by a
235 single caller it could be moved into place. This could enhance deductions based on
236 attribute usage since observations from the inlined function would be merged into the
237 caller.
238
239 Distinguish between frame sharing and inlining: where a called function does not rebind
240 its names, and where the frame of the caller is compatible, the frame of the caller might
241 be shared with the called function even if a branch and return is still involved.
242
243 Suitable candidates for inlining, frame sharing or enhanced analysis might be lambdas and
244 functions containing a single statement.
245
246 Consider what it would take to support the inlining or analysis of this in the operator
247 module...
248
249 add(x, y) -> binary_op(x, y, lambda a: a.__add__, lambda b: b.__radd__)
250 -> x.__add__(y) ; y.__radd__(x)
251
252 Function Specialisation
253 =======================
254
255 Specialisation of certain functions, such as isinstance(x, cls) where cls is a known
256 constant.
257
258 Structure and Object Table Optimisations
259 ========================================
260
261 Fix object table entries for attributes not provided by any known object, or provide an
262 error, potentially overridden by options. For example, the augmented assignment methods
263 are not supported by the built-in objects and thus the operator module functions cause
264 the compilation to fail. Alternatively, just supply the methods since something has to do
265 so in the builtins.
266
267 Consider attribute merging where many attributes are just aliases for the same underlying
268 definition.
269
270 Consider references to defaults as occurring only within the context of a particular
271 function, thus eliminating default value classes if such functions are not themselves
272 invoked.
273
274 Scope Handling
275 ==============
276
277 Consider merging the InspectedModule.store tests with the scope conflict handling.
278
279 Consider labelling _scope on assignments and dealing with the assignment of removed
280 attributes, possibly removing the entire assignment, and distinguishing between such cases
281 and unknown names.
282
283 Check name origin where multiple branches could yield multiple scope interpretations:
284
285 try:
286 set # built-in name
287 except NameError:
288 from sets import Set as set # local definition of name
289
290 set # could be confused by the local definition at run-time
291
292 Object Coverage
293 ===============
294
295 Support __init__ traversal (and other implicit names) more effectively.
296
297 Importing Modules
298 =================
299
300 (Explicit relative imports are now supported.) Consider supporting relative imports, even
301 though this is arguably a misfeature.
302
303 Other
304 =====
305
306 Check context_value initialisation (avoiding or handling None effectively).
307
308 Consider better "macro" support where new expressions need to be generated and processed.
309
310 Detect TestIdentity results involving constants, potentially optimising status-affected
311 instructions:
312
313 TestIdentity(x, y) # where x is always y
314 JumpIfFalse(...) # would be removed (never false)
315 JumpIfTrue(...) # changed to Jump(...)
316
317 Status-affected blocks could be optimised away for such constant-related results.
318
319 Caching of structure and attribute usage information for incremental compilation.