And if these baby steps On 27 Mar 2008 21:17:58 +0300, Egor Pasko <[EMAIL PROTECTED]> wrote: > On the 0x413 day of Apache Harmony Okonechnikov Konstantin wrote: > > Well, there are some questions. > > [IrBuilder] > > If we clean out simplification, it wont affect the functionality of > > instructions, will it? (i.e.will OPT work without these simplifications? > > I ve tried to clean some instructions, it seems everything is OK > (HelloWorld > > works) ) > > Ideally everything should work if we disable simplification. Although > I remember some problems running Eclipse solely on OPT with > simplification disabled. That was a long time ago, and if it appears, > that's a bug. > > > > I 've written sort of plan. Check this out. > > 1) Clean up IRBuilder > > -remove Simplifier and its methods > > sounds good > > > > 2) Move all simplification to Optimizer stage > > (this is quite big task as I suppose, lots of instructions use > > simplification. Not sure if we should create separate action for every > > simplification....) > > 1 and 2 should be implemented concurrently > > actually there is a stage called 'simplify' already that in fact uses > the same simplifier. So, it is not a huge work, need to ask somebody > to check performance of disabling simplification in translator and > running it from HLO right after the translator (with dead code > eliminator, blablabla). > > > > 3) Develop the translator > > - new PrePass (maybe from Jet?) > > > > - implement data analisys, parser etc... > > > > Where am I mistaken? I will appreciate any additions and(or) corrections. > > Kostya, thanks a lot for the draft plan! I have been quite busy and > could not discuss it with you earlier. Sorry for that. I like your > pro-active approach very much, please continue behave like that :) > > Although, I have somewhat different views on the plan, those views are > more like discussable than final :) So, plz, do not take personally if > I just ruined your best dreams about the process)) > > TA-DAA! Here my suggestion goes.. > > I would recomend to hack the whole code starting from a small and > limited implementation and grow functionality doing small baby > steps. So, you would not need to implement the rock solid data flow > analysis at once. Just write one that looks beautiful by design, does > not support non-interesting instructions as well as difficult stuff > like exceptions, loops and JSR/RET, put asserts in places, where you > do not support something. > > Then grow functionality until you can run HelloWorld. Constantly > ensuring that the code looks good and we love it. > > This can be split into several sub-steps: > > 0. move simplifier out of IRBuilder, basically fix HARMONY-5500 or > determine that it is not a part of our work if it unexpectedly > wants to eat too much time :) > > 1. draft code that does prepass and data flow analysis in code _without_ > loops, exceptions, call instructions > 1.1. prepass > 1.2. data flow analysis > 1.3. bytecode mapping > > 2. support call instructions and lazy resolution > > 3. with loops > > 4. with exceptions and loops > > 5. make sure Hello World works and fix bugs when it does not ;) > > 6. JSR/RET support > > 7. inliner support > > 8. make sure all tests and eclipse work in -Xem:opt mode > 8.1. bytecode without JSR/RET > 8.2. bytecode obtained by ECJ (with JSR/RET) > > 9. write barriers (?), other features... > > 10. what I forgot > > (I am yet not sure about the order, though, pick what you want to do > first) > > Let's review the code between steps, speak about it, think what we do > next and how. It also makes sense to review the code more often, once > noticeable features are implemented or code is refactored. > > My picture is that we will commit it into a separate directory, your > code can be running via tweaked emconf file. That is because I do not > like branches :) > > I separated exceptions, loops, resolution stuff because I think it > will let us better concentrate on coding in the early stages (what > else to separate?). Additionally, I think, exception support needs > little change. It has been completely rewritten once, looks not so bad > (although scattered around) and no bugs were found in it since > then. So, just move the code carefully. Same picture with JSR/RET > support. Looks like no need to rewrite. > > Why is this approach worth trying? Because you can test the code while > writing. Make an emconf that uses your code on methods with supported > bytecodes and use JET or older OPT for others. > > Sounds good? > > -- > Egor Pasko > >
-- With best regards, Alexei
