Bug 1868: Specifying Pass Orderings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug 1868: Specifying Pass Orderings

John Criswell-3
Dear Devang Patel,

In response to your comment on bug 1868, how do I get BottomPass to
requires Pass2 before Pass1?  Is it by reversing the order of the calls
to AU.addRequired()?

-- John T.

--
John T. Criswell
[hidden email]

"It's today!" said Piglet. "My favorite day," said Pooh.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Bug 1868: Specifying Pass Orderings

Devang Patel

On Dec 17, 2007, at 1:47 PM, John Criswell wrote:

> Dear Devang Patel,
>
> In response to your comment on bug 1868, how do I get BottomPass to
> requires Pass2 before Pass1?  Is it by reversing the order of the  
> calls
> to AU.addRequired()?

yup :)

-
Devang


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Bug 1868: Specifying Pass Orderings

John Criswell-3
Devang Patel wrote:

>
> On Dec 17, 2007, at 2:01 PM, John Criswell wrote:
>
>> Devang Patel wrote:
>>>
>>> On Dec 17, 2007, at 1:47 PM, John Criswell wrote:
>>>
>>>> Dear Devang Patel,
>>>>
>>>> In response to your comment on bug 1868, how do I get BottomPass to
>>>> requires Pass2 before Pass1?  Is it by reversing the order of the
>>>> calls
>>>> to AU.addRequired()?
>>>
>>> yup :)
>> So what do I do if both Pass1 and Pass2 preserve nothing?  Is that just
>> unschedule'able with the current Pass Manager?
>
> I am afraid so.
>
>> Both Pass1 and Pass2 are transforms in the original program (the test
>> case is a contrived version to demonstrate the issue).
>
> If they are transforms then technically they are not required by
> BottomPass because they are not analysis.
>
> getAnalysisUsage() interface is not meant to schedule order of
> transformation passes. It is to ensure that analysis required by a
> transformation pass available and up-to-date when transformation pass
> is run.
Okay.  I was afraid of that.  It used to work that way in LLVM 1.9, but
it seems it's changed.

>
> Do you really "require" Pass1 and Pass2 to run BottomPass or do you
> expect LLVM IR is processed by Pass1 and Pass2 before BottomPass is
> invoked ?
Both, actually.  I'm working on SAFECode, which is built as several
transform passes that run after the automatic pool allocation pass.  I
believe they not only require pool allocation to be run first, but they
also query the pool allocation pass for information on what it has done
(e.g. to determine if a function is a clone of an original function, and
if so, determine what the original function was).

Now that I think about it, I might be able to adjust the SAFECode passes
so that they preserve pool allocation's results.  That might fix it.

So, is there a way for a Pass to specify that other transforms should be
run first, or can that only be done with PassManager.add()?

-- John T.

>
>>  I'm not sure
>> that I can get one of them to preserve the other.
>>
>> -- John T.
>>
>>>
>>> -
>>> Devang
>>>
>>
>>
>> --
>> John T. Criswell
>> [hidden email]
>>
>> "It's today!" said Piglet. "My favorite day," said Pooh.
>>
>>
>
> -
> Devang
>
>


--
John T. Criswell
[hidden email]

"It's today!" said Piglet. "My favorite day," said Pooh.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Bug 1868: Specifying Pass Orderings

Devang Patel

On Dec 17, 2007, at 2:25 PM, John Criswell wrote:

> So, is there a way for a Pass to specify that other transforms  
> should be
> run first, or can that only be done with PassManager.add()?


PassManager.add() is the way to go.

If one relies on PassManager to order transformations passes properly  
then we are stepping into "Find optimal ordering of optimization/
transformations passes sequence to generate the best code for my  
application" area. I'd prefer to stay out of that, because it is non-
trivial. Instead, let PassManager users (e.g. llvm-gcc, opt. SAFECode  
driver?) decide the ordering of transformations.

-
Devang
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Bug 1868: Specifying Pass Orderings

John Criswell
Devang Patel wrote:

> On Dec 17, 2007, at 2:25 PM, John Criswell wrote:
>
>  
>> So, is there a way for a Pass to specify that other transforms
>> should be
>> run first, or can that only be done with PassManager.add()?
>>    
>
>
> PassManager.add() is the way to go.
>
> If one relies on PassManager to order transformations passes properly
> then we are stepping into "Find optimal ordering of optimization/
> transformations passes sequence to generate the best code for my
> application" area.
I would actually disagree on that point.  Supporting optimal code
generation is an orthogonal design goal.  For example, the old
PassManager did not guarantee optimal code generation.  It only ensured
that all prerequisite transforms and analysis passes were run first and
tried to minimize re-running analysis passes as much as possible.

However, that's just food for thought.  I'm not sure what the correct
thing is to do long term (and I don't have time to implement it even if
I did).  For now, I'll just try to get the code working within the
constraints you mentioned.

> I'd prefer to stay out of that, because it is non-
> trivial. Instead, let PassManager users (e.g. llvm-gcc, opt. SAFECode
> driver?) decide the ordering of transformations.
>  
Thanks for your help!

-- John T.
> -
> Devang
>  

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev