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 Wed, 18 Oct 2006 08:28:33 GMT
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


Mime
View raw message