On 14 December 2010 11:57, David Malcolm <[email protected]> wrote: > One other idea I had was to sort the blocks in the function by the > bytecode offset; currently the c blocks seem to "jump around" a fair bit > relative to the corresponding rpython code. Has any tuning been done on > the ordering of the blocks within the generated .c code? (or is it > assumed that the .c compiler will "flatten" these, for the case when a > node has a single successor node?) > > (I wonder if similar work could be done on the JVM and CLI code > generators?)
An unfortunate consequence of abstract interpretation is that you loose a fair bit of the structure of the code as it appears in the source. There are situations, for example, where you can't know which blocks (or which *part* of which blocks, even) are part of an inner and which are part of an outer loop. The existing code (at least when writing jitcode, but I imagine it's the same for the backend) writes the startblock, and then immediately writes its first dependency - essentially a depth-first traversal, a method as good as any in the absence of structure, but I would be interested to see what difference it makes for what cost in extra translation time. -- William Leslie _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
