harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
Date Thu, 19 Oct 2006 15:08:46 GMT
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 <egor.pasko@gmail.com> 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 <egor.pasko@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> >
> > --
> > Egor Pasko, Intel Managed Runtime Division
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
> 
> 
> -- 
> Mikhail Fursov

-- 
Egor Pasko, Intel Managed Runtime Division


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message