Re: [drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
On 19 Oct 2006 22:08:46 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote: 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. Yes, I will be busy this month with more critical tasks. This is the only reason I postpone it. -- Mikhail Fursov
Re: [drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
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 <[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) > >
Re: [drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
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 inf
Re: [drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
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 p
Re: [drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
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. Thank you, Pavel 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
Re: [drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
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]
Re: [drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
Mikhail, Good proposal. Thinking of HIR as consisting from a core CFG part (including instructions of course) and an auxiliary info we could impose certain requirements on the CFG part between actions and implement a framework to (re-)calculate the auxiliary info from the CFG part on demand. IMO this is the case with the IA32 CG - auto-tracked liveness and loop info is auxiliary info and the state of the CFG LIR part is well-defined between transformations. So: 1) I do. 2,4) As for the CFG part - whatever brings it to a well-defined valid state (is UCE enough?) As for the auxiliary info - if we want it similar to the CG, we might think about different aux. infos like loop, dominator trees, etc. 3) UCE - after an optimization but within the corresponding action (to keep HIR valid between actions). Auxilary info - on demand if outdated. -- Slava Shakin "Mikhail Fursov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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? > 2) What passes to integrate into HLO pipeline as a base optimizer's > functionality? > 3) When to "fix" the IR - before or after a pipeline action. (See my > comments with examples below) > 4) What other HLO passes could be integrated into the optimizer's > pipeline? > > > > My answers are: > 1) I agree :) > 2) SSA, DESSA, UCE. Do not touch DCE and leave it as a separate > optimization pass. > 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. > 4) ? > > Waiting for your opinion.. > > > -- > Mikhail Fursov > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][jit] New task for JIT volunteers: refactoring Jitrino.OPT optimizer's pipeline
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? 2) What passes to integrate into HLO pipeline as a base optimizer's functionality? 3) When to "fix" the IR - before or after a pipeline action. (See my comments with examples below) 4) What other HLO passes could be integrated into the optimizer's pipeline? My answers are: 1) I agree :) 2) SSA, DESSA, UCE. Do not touch DCE and leave it as a separate optimization pass. 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. 4) ? Waiting for your opinion.. -- Mikhail Fursov
