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..
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
