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
