On the 0x207 day of Apache Harmony Mikhail Fursov wrote: > So I'll add this task with results of the discussion to the "JIT tasks" > page. > BTW the refactoring could be done as a part of the > http://issues.apache.org/jira/browse/HARMONY-1905 fix. But 1905 could be > fixed easier of course..
since the bug is not critical (jitrino-debug mode only, which is not what everyone builds) I vote for the refactoring way in HARMONY-1905. Are you adding this task because you want to postpone it a little? Otherwize I do not see the reason in updating the Wiki page. > On 18 Oct 2006 15:28:33 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > On the 0x206 day of Apache Harmony Pavel Ozhdikhin wrote: > > > Many words have been said in support of this proposal and I second it > > too. > > > The Optimizer framework will do less redundant work - currently clean-up > > > passes are invoked even if the CFG has not been modified by an > > optimization. > > > So, refactoring will optimize the optimizer. :) > > > > > > > > 1) Does everyone agree that we need such a refactoring? > > > > > > Sure. > > > > > > > > 2) What passes to integrate into HLO pipeline as a base optimizer's > > > > > functionality? > > > > > > It makes sense to start with relatively "big" items. Many flags > > controlling > > > current CFG state and desired state for an optimizations will add extra > > > complexity. For example, ssa, de-ssa, fixup-ssa, uce affect core IR > > state > > > and IMO worth to be included into the framework. LoopInfo, dominatorTree > > etc > > > are entities derived from the core IR and can be re-calculated when > > needed. > > > > > > > > 3) When to "fix" the IR - before or after a pipeline action. (See > > my > > > > > comments with examples below) > > > > > > It depends on the functionality. If this is "switch" to a different IR > > state > > > "ssa/de-ssa" - before. If it's a clean up of current IR state - I'd > > prefer > > > to have it clean after any optimization. > > > > Pavel, > > we have identical vision. Promising! :) > > > > > On 18 Oct 2006 12:40:03 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: > > > > 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] > > > > > > > > > > > > -- > > 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] > > > > > > > -- > Mikhail Fursov -- 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]
