On Fri, Jul 23, 2010 at 11:26 AM, stefan brunthaler <ste...@brunthaler.net> wrote: >> I'm guessing from your comments below about cross-module inlining that >> you generate a separate .c file with the specialized opcode bodies and >> then call through to them via a table of function pointers indexed by >> opcode, but I could be totally wrong. :) >> > No, dead on ;) > Probably a small example from the top of my head illustrates what is going on: > > TARGET(FLOAT_ADD): > w= POP(); > v= TOP(); > x= PyFloat_Type.tp_as_number->nb_add(v, w); > SET_TOP(x); > if (x != NULL) FAST_DISPATCH(); > break; > > And I extend the standard indirect threaded code dispatch table to > support the FLOAT_ADD operation.
I think I was wrong, but now I understand. The inlining you want is to get the nb_add body, not the opcode body. The example you've given brings up a correctness issue. It seems you'd want to add checks that verify that the operands w and v are both floats, and jump to BINARY_ADD if the guard fails. It would require reshuffling the stack operations to defer the pop until after the check, but it shouldn't be a problem. >> This would be interesting. We have (obviously) have similar >> instrumentation in unladen swallow to gather type feedback. We talked >> with Craig Citro about finding a way to feed that back to Cython for >> exactly this reason, but we haven't really pursued it. >> > Ok; I think it would actually be fairly easy to use the type > information gathered at runtime by the quickening approach. Several > auxiliary functions for dealing with these types could be generated by > my code generator as well. It is probably worth looking into this, > though my current top-priority is my PhD research, so I cannot promise > to being able to allocate vast amounts of time for such endeavours. I think you also record (via gdb) exactly the information that we record. I now see three consumers of type feedback from the CPython interpreter: you or any quickening approach, Cython, and Unladen Swallow. It might be worth converging on a standard way to record this information and serialize it so that it can be analyzed offline. Our feedback recording mechanism currently uses LLVM data structures, but the point of quickening is to avoid that kind of dependency, so we'd need to rewrite it before it would really be useful to you. Reid _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
