Hi Graham, On Fri, Jun 5, 2009 at 12:03 PM, Paul Biggar<paul.big...@gmail.com> wrote: >> Why not start off with the big stuff, dataflow. I personally believe that >> working out good data flow for PHP is key to getting good optimizations. But >> you are right, its a very tricky thing to do and in some cases impossible. >> Ultimately, I would like to move a lot of the optimizer work more into this >> direction and use the data flow to build a basic platform for code analysis >> on which optimizations can be done. For now though, pecl/optimizer is "dumb" >> about data types :-) > > > And now the hard stuff. To avoid me repeating myself, let me just pimp > my Tech Talk. Have a look at > http://www.youtube.com/watch?v=kKySEUrP7LA from about the 30:45 mark > until just before the 47:00 mark (slides at > https://www.cs.tcd.ie/~pbiggar/paul_biggar_google_18_mar_2009_notes.pdf). > That highlights most of the problems, and vaguely hints at their > solution. We can go into much greater detail on the solutions after.
Based on the fact that you want to do dataflow, I wonder if its a good idea to think about co-opting the phc optimizer to perform analysis on bytecode. To my mind this seems much easier than re-implementing from scratch. As I mentioned before, this incorporates about 2 years of work (much of it research of course, so it might not take as long to replicate). This would mean you could go straight to performing analyses (though there will no doubt be work required on the optimizer itself). Technically speaking, this isn't a big problem. We'd probably need to change the phc MIR to mirror the bytecode (no harm anyway in terms of correctness), and have a bytecode-reader and -writer (though this needn't involve serializing - likely a small interface instead). Politically, I assume it won't be a problem either, since its in PECL. Thoughts? Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
