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