Hi Manuel, We've been suitably impressed by the results on the new llvm backend during the sprint (well, or suitably un-impressed by both gcc and clang's failure to reconstruct the SSA meaning of the C code).
The current issue seems to be debugging. It would be nice if gdb presented at least source ".ll" code rather than just the assembler instructions --- actually, it would be more than nice: debugging at the level of assembler is a no-no. I was thinking: would it make sense to emit from the translation toolchain some files that are not in ".ll" format, but that are more or less a straightforward text file representation of the flow graphs and constants, and then have a separate tool that converts these files (seen as source) into .ll files? There are some advantages of doing it this way, even if it looks like Yet Another intermediate step. The first advantage is that it would give some inspectable files, which we could also request during testing for cases where the pygame flow graph inspector doesn't really work (e.g. too many graphs). Another advantage is that we might refactor the C backend to also be a separate tool that inputs these flowgraph text files, minimizing the amount of duplicate work between the C and the LLVM backends. And of course, the point is that the flowgraph-to-".ll" conversion would insert file line numbers, so that we can debug it in gdb seeing the flowgraph source lines. (I can even think about hacks to do the same even if we go via C...) Of course the drawback is that it's some non-trivial refactorization. Does it make sense? A bientôt, Armin. _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
