Mikhail, great proposal! Implementing it would make us not only a better and more usable infrastricture in Jitrino.OPT, but will fix some imminent bugs right away. +1 from me!
On the 0x205 day of Apache Harmony Mikhail Fursov wrote: > JIT gurus, > I want to add this task to the list of the opened JIT tasks. But before > doing it let's discuss the details. > The task is to simplify the optimizer's pipeline and move some supplementary > actions like ssa,dessa,uce,dce into the base optimizer action. > That is if an optimization pass needs to have IR in SSA form or needs to > have IR without unreachable nodes, it just set ups the flag and the base > implementation of the optimizer's action prepares IR before running the > optimization. The same functionality is already done in IA32 CodeGenerator: > the liveness info is prepared if the flag of the IA32 CG action is set. > > So the questions are: > 1) Does everyone agree that we need such a refactoring? I do! It has been some time we did not share any cleanness info between optimizations. Which needs a fix. > 2) What passes to integrate into HLO pipeline as a base optimizer's > functionality? can all optimizations show that they can possibly make IR not valid in a certain way? For example, Simplifier can make unreachable nodes (BTW, can it?), but cannot invalidate SSA. So we will need to run UCE, but not fixupSSA. Optimizations that are not easy (covered by mistery) can say that they invalidate IR in _all_ possible ways. This would mean that all kinds of cleanup will be performed. This is surely some knowledge put explicitly as the optimization's property (and can become outdated without proper care), and it is not always easy to say what specific aspects of IR an opt-pass can make disfunctioning. But this kind of info makes us a "convention" info how the opt-pass behaves. currently, whith SSA it happens like that. Some opt-passes (loop peeling, for example) explicitly call fixupSSA if they have to I support the idea to make UCE integrated. What about SSA? Some optimization passes can say explicitly that: * they require SSA, * they require no phi instructions (no SSA) * they do not care about SSA * they possibly make SSA invalid * they possibly make SSA invalid if the IR is in SSA (in case they do not care) > 3) When to "fix" the IR - before or after a pipeline action. (See my > comments with examples below) "before" is a matter of lazyness, "after" is a matter of cleanness in all situations which is more aesthetically acceptable. "after" has less states (especially if we take my above "invalidation aspects" proposal). I like this "after", with "aspects". > 4) What other HLO passes could be integrated into the optimizer's pipeline? Good idea from Slava on loop info! (which we do not want to rebuild too often). BTW, do we have a quick fixupLoopInfo()? Makes sense, if it can be faster (can it?:) Dominators .. hm, there should be a compromise. Should we care about the time it takes to rebuild the info, and the effort it takes to mark all optimizations in proper relevance to the info (and maintain it throughout the optimization pipeline). I think, Dominators are better rebuilt upon request. > My answers are: > 1) I agree :) I had almost no doubt :) > 2) SSA, DESSA, UCE. Do not touch DCE and leave it as a separate > optimization pass. /me OK with it. Let's think about loop info too. Would it be easy to maintain or rebuild upon request? IMHO, loop info in HLO can be always rebuilt on request. Not sure about CG. > 3) Do UCE right after the optimization that modifies CFG. Do SSA and DESSA > right before the optimization that requires ssa or dessa IR's form. some optimizations are insensitive to SSA. We can either make them sensitive or put another possibility: "ignores SSA-ness" > 4) ? > > Waiting for your opinion.. thanks for that! -- Egor Pasko, Intel Managed Runtime Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
