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 05:40:03 GMT

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

View raw message