I'm sorry. Please, disregard the previous letter. On Fri, Mar 28, 2008 at 1:09 AM, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > 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 >
-- With best regards, Alexei
