paul@413 | 1 | Dynamic Attribute Access
|
paul@413 | 2 | ========================
|
paul@413 | 3 |
|
paul@413 | 4 | Ensure that getattr (or other dynamic attribute usage) causes propagation of coverage to
|
paul@413 | 5 | the potential attributes.
|
paul@413 | 6 |
|
paul@413 | 7 | Consider explicit accessor initialisation.
|
paul@413 | 8 |
|
paul@394 | 9 | Attribute Usage
|
paul@394 | 10 | ===============
|
paul@394 | 11 |
|
paul@390 | 12 | Consider attribute assignment observations, along with the possibility of class attribute
|
paul@390 | 13 | assignment.
|
paul@372 | 14 |
|
paul@404 | 15 | Note direct assignments as usual, indirect assignments via the attribute usage
|
paul@404 | 16 | mechanism. During attribute collection and inference, add assigned values to all
|
paul@404 | 17 | inferred targets.
|
paul@404 | 18 |
|
paul@404 | 19 | Since class attributes can be assigned, StoreAttrIndex would no longer need to reject
|
paul@404 | 20 | static attributes, although this might still be necessary where attribute usage analysis
|
paul@404 | 21 | has not been performed.
|
paul@404 | 22 |
|
paul@404 | 23 | Potentially consider changing static attribute details to use object-relative offsets in
|
paul@404 | 24 | order to simplify the instruction implementations. This might allow us to eliminate the
|
paul@404 | 25 | static attribute flag for attributes in the object table, at least at run-time.
|
paul@404 | 26 |
|
paul@372 | 27 | Consider attribute usage observations being suspended inside blocks where AttributeError
|
paul@372 | 28 | may be caught (although this doesn't anticipate such exceptions being caught outside a
|
paul@372 | 29 | function altogether).
|
paul@372 | 30 |
|
paul@364 | 31 | Consider type deduction and its consequences where types belong to the same hierarchy
|
paul@364 | 32 | and where a guard could be generated for the most general type.
|
paul@364 | 33 |
|
paul@364 | 34 | Consider permitting multiple class alternatives where the attributes are all identical.
|
paul@364 | 35 |
|
paul@360 | 36 | Support class attribute positioning similar to instance attribute positioning, potentially
|
paul@360 | 37 | (for both) based on usage observations. For example, if __iter__ is used on two classes,
|
paul@360 | 38 | the class attribute could be exposed at a similar relative position to the class (and
|
paul@360 | 39 | potentially accessible using a LoadAttr-style instruction).
|
paul@360 | 40 |
|
paul@394 | 41 | **** Constant attribute users need not maintain usage since they are already resolved. ****
|
paul@394 | 42 |
|
paul@394 | 43 | Loop entry points should capture usage to update later assignments in the loop.
|
paul@394 | 44 | The continue and break statements should affect usage propagation.
|
paul@394 | 45 |
|
paul@394 | 46 | Consider handling CallFunc in micropython.inspect in order to produce instances of specific classes.
|
paul@394 | 47 | Then, consider adding support for guard removal/verification where known instances are involved.
|
paul@394 | 48 | Consider handling branches of values within namespaces in order to support more precise value usage.
|
paul@394 | 49 |
|
paul@394 | 50 | Frame Optimisations
|
paul@394 | 51 | ===================
|
paul@394 | 52 |
|
paul@394 | 53 | Stack frame replacement where a local frame is unused after a call, such as in a tail call
|
paul@394 | 54 | situation.
|
paul@394 | 55 |
|
paul@394 | 56 | Local assignment detection plus frame re-use. Example: slice.__init__ calls
|
paul@394 | 57 | xrange.__init__ with the same arguments which are unchanged in xrange.__init__. There is
|
paul@394 | 58 | therefore no need to build a new frame for this call.
|
paul@394 | 59 |
|
paul@394 | 60 | Function Specialisation
|
paul@394 | 61 | =======================
|
paul@394 | 62 |
|
paul@394 | 63 | Specialisation of certain functions, such as isinstance(x, cls) where cls is a known
|
paul@394 | 64 | constant.
|
paul@394 | 65 |
|
paul@394 | 66 | Structure and Object Table Optimisations
|
paul@394 | 67 | ========================================
|
paul@394 | 68 |
|
paul@394 | 69 | Fix object table entries for attributes not provided by any known object, or provide an
|
paul@394 | 70 | error, potentially overridden by options. For example, the augmented assignment methods
|
paul@394 | 71 | are not supported by the built-in objects and thus the operator module functions cause
|
paul@394 | 72 | the compilation to fail. Alternatively, just supply the methods since something has to do
|
paul@394 | 73 | so in the builtins.
|
paul@394 | 74 |
|
paul@394 | 75 | Consider attribute merging where many attributes are just aliases for the same underlying
|
paul@394 | 76 | definition.
|
paul@394 | 77 |
|
paul@349 | 78 | Consider references to defaults as occurring only within the context of a particular
|
paul@349 | 79 | function, thus eliminating default value classes if such functions are not themselves
|
paul@349 | 80 | invoked.
|
paul@349 | 81 |
|
paul@394 | 82 | Scope Handling
|
paul@394 | 83 | ==============
|
paul@394 | 84 |
|
paul@394 | 85 | Consider merging the InspectedModule.store tests with the scope conflict handling.
|
paul@394 | 86 |
|
paul@343 | 87 | Consider labelling _scope on assignments and dealing with the assignment of removed
|
paul@343 | 88 | attributes, possibly removing the entire assignment, and distinguishing between such cases
|
paul@343 | 89 | and unknown names.
|
paul@343 | 90 |
|
paul@342 | 91 | Check name origin where multiple branches could yield multiple scope interpretations:
|
paul@342 | 92 |
|
paul@342 | 93 | ----
|
paul@342 | 94 | try:
|
paul@342 | 95 | set # built-in name
|
paul@342 | 96 | except NameError:
|
paul@342 | 97 | from sets import Set as set # local definition of name
|
paul@342 | 98 |
|
paul@342 | 99 | set # could be confused by the local definition at run-time
|
paul@342 | 100 | ----
|
paul@342 | 101 |
|
paul@394 | 102 | Object Coverage
|
paul@394 | 103 | ===============
|
paul@394 | 104 |
|
paul@332 | 105 | Support __init__ traversal (and other implicit names) more effectively.
|
paul@332 | 106 |
|
paul@394 | 107 | Other
|
paul@394 | 108 | =====
|
paul@394 | 109 |
|
paul@408 | 110 | Support tuple as a function returning any input tuple uncopied.
|
paul@408 | 111 |
|
paul@332 | 112 | Check context_value initialisation (avoiding or handling None effectively).
|
paul@332 | 113 |
|
paul@342 | 114 | __getitem__ could be written in Python, using a native method only to access fragments.
|
paul@349 | 115 |
|
paul@342 | 116 | Consider better "macro" support where new expressions need to be generated and processed.
|
paul@402 | 117 |
|
paul@402 | 118 | Detect TestIdentity results involving constants, potentially optimising status-affected
|
paul@402 | 119 | instructions:
|
paul@402 | 120 |
|
paul@402 | 121 | TestIdentity(x, y) # where x is always y
|
paul@402 | 122 | JumpIfFalse(...) # would be removed (never false)
|
paul@402 | 123 | JumpIfTrue(...) # changed to Jump(...)
|
paul@402 | 124 |
|
paul@402 | 125 | Status-affected blocks could be optimised away for such constant-related results.
|