harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Ozhdikhin" <pavel.ozhdik...@gmail.com>
Subject Re: [drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
Date Wed, 18 Oct 2006 07:02:21 GMT
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?


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

Thank you,

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message