llvm dev - May 2006 - [LLVMdev] Conflicting passes?

Hi,
> On Wed, 3 May 2006, Domagoj D wrote:
> > I thought so. However, it's not clear to me why
"preservation" is
> > required at all?
> > That's just an optimization. The PassManager should be able to 
> > run passes with
> > interdependencies by serializing them (for example in the order as
they were
> > added to the queue).
> >
> > This way, users simply have no other choice but to write batch 
> > scripts, unless
> > if I'm missing something.
> 
> Please read:
> http://llvm.org/docs/WritingAnLLVMPass.html
> 
> carefully.
> 
> -Chris
I have and found nothing that contradicts what I said:
a) I still don't see a way to use such conflicting passes within a
single pass that requires them both

b) Sequencing and "property preservation" still look like optimization
to me (a very useful, but also limiting one). If runOnFunction() calls
are assumed to be independent, for each function, the PassManager could
call:

UnifyFunctionExitNodes which destroys all properties, and 
LowerSwitchID, which should be able to rebuild what it needs.

The order might be implementation-dependent, and that's the only problem
I see. However, in this case those two passes do orthogonal transforms,
and it doesn't really matter which runs first. Even if it does, the
sequence of addRequired<>() calls might be (perhaps) used to handle
that. 


I'm still striving to understand LLVM architecture, both its limitations
and virtues... Any help would be appreciated.

Thx.

Domagoj



-- 
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/

On Wed, 3 May 2006, Domagoj D wrote:
> I have and found nothing that contradicts what I said:
> a) I still don't see a way to use such conflicting passes within a
> single pass that requires them both
Right.  There is no way.  If you have two passes which provide (in this 
case) CFG properties "A" and "B", and pass A break property
"B" and pass B
breaks property "A", there is no way to get the CFG with both
properties
at the same time.
> b) Sequencing and "property preservation" still look like
optimization
> to me (a very useful, but also limiting one). If runOnFunction() calls
> are assumed to be independent, for each function, the PassManager could
> call:
No.  The "requires" capability of the pass manager has has nothing to
do
with sequencing.  If you want *sequencing*, just add the passes to the 
pass manager in some order.  The "requires" capability is there for
passes
that need some analysis information or property (e.g. critical edges 
broken) to be active when they run.
> UnifyFunctionExitNodes which destroys all properties, and
> LowerSwitchID, which should be able to rebuild what it needs.
>
> The order might be implementation-dependent, and that's the only
problem
> I see. However, in this case those two passes do orthogonal transforms,
> and it doesn't really matter which runs first. Even if it does, the
> sequence of addRequired<>() calls might be (perhaps) used to handle
> that.
Right.  The issue is that there is no way to hack this into working.  If 
you want to have a pass that depends on both "no switch statements"
and
"unified exits" (which are not conflicting here) you need to update
the
UnifyExits and LowerSwitch passes to know that they don't invalidate each 
other.  This should just be a matter of adding an addPreserves<> 
somewhere.  In this case, neither pass invalidates each other.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/