Armin Rigo wrote:
On Thu, Sep 30, 2004 at 01:02:34PM -0700, Brett C. wrote:
(101, ('BINARY_MULTIPLY', (8, 4))), (106, ('BINARY_SUBSCR', 128)), (118, ('GET_ITER', 128)), (124, ('BINARY_MODULO', None)), (195, ('meth_join', 4)), (204, ('BINARY_ADD', (8, 8))), (331, ('BINARY_ADD', (4, 4))), (513, ('BINARY_LSHIFT', (8, 8))), (840, ('meth_append', 128)), (1270, ('PRINT_ITEM', 4)), (1916, ('BINARY_MODULO', 4)), (12302, ('STORE_SUBSCR', 64))]
I was surprized at first to see so few operations involving integers. There isn't even LOAD_SUBSCR for a list and an integer, though I believe it to be a very common operation.
It's picked up and listed above; 106 times. I already type check that lists are being indexed by integer or an object so I didn't bother to keep separate stats for those two cases.
It makes me guess that your type-inferencer does not recognize 'i' to be an integer in constructions like
for i in range(...)
Right, I don't infer those situations.
If so, it might be worth considering that some built-ins (most likely range(), len(), enumerate()) should be treated specially. Remember there was also discussion in this list at some point about the compiler producing opcodes like BUILTIN_LEN. This means that it might be acceptable to break the precise semantics (which involve looking up the name 'len' or 'range' in the globals first) and just special-case these common built-ins.
Not going to break semantics for my thesis (the whole was not to), but this is all going to be mentioned in the Future Work section on what can be done to improve the situation for type inferencing. It would definitely help if built-ins were known at compile-time, but since I have limited time I had to limit myself to what could be done without adding features to the compiler beyond just type inferencing.