llvm dev - Mar 2011 - [LLVMdev] pass statistic

Hi folks,

I wonder how to get the statistic of  which pass has been "really"  
applied and which one is not. For instance, I try to apply 20 llvm  
passes on a single C source code. But since the precondition of each  
pass may not be satisfied (try loop-unrolling to a source code without  
loop), some of these pass may not affect the final result. How to know  
which pass affect and which one is ignored? Does Llvm have this kind  
of statistic? Thanks.

Best,

Kecheng

On 3/9/2011 11:26 PM, kecheng at cecs.pdx.edu wrote:
> Hi folks,
>
> I wonder how to get the statistic of  which pass has been
"really"
> applied and which one is not. For instance, I try to apply 20 llvm
> passes on a single C source code. But since the precondition of each
> pass may not be satisfied (try loop-unrolling to a source code without
> loop), some of these pass may not affect the final result. How to know
> which pass affect and which one is ignored? Does Llvm have this kind
> of statistic? Thanks.
One option is to use the -stats option with opt and hope that a 
transform keeps statistics on how many transforms it makes.  However, 
this approach is fragile because an arbitrary LLVM pass may not record 
any statistics on what it changes.

Another approach is to use the -debug-pass=details option in opt.  I 
believe it will tell you when a pass has modified the code and when it 
has not.  That said, some transform passes may tell the PassManager that 
they've modified the program when, in fact, they haven't simply because 
it's too much programming work to track, within the pass, whether it has 
modified anything.

A third option might be to write a pass that somehow records the current 
state of the bitcode and compares it to the state it saw when it last 
executed.  You could then run this pass in between every other pass to 
detect cases where the module does not change.

So, there are some ways to do it, but only the third option (the most 
time-consuming to do) looks fool-proof.

-- John T.
> Best,
>
> Kecheng
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi,

It looks that the third way would be the most accurate, and won't  
generate a false alarm.

I think I can do some simple experiment first. I want to dump the  
bitcodes  before and after applying each pass and I don't want to  
insert the dumping code to every llvm pass. Is there a good place to  
do this once for all passes? Thanks.

Best,

Kecheng


Quoting John Criswell <criswell at illinois.edu>:
> On 3/9/2011 11:26 PM, kecheng at cecs.pdx.edu wrote:
>> Hi folks,
>>
>> I wonder how to get the statistic of  which pass has been
"really"
>> applied and which one is not. For instance, I try to apply 20 llvm
>> passes on a single C source code. But since the precondition of each
>> pass may not be satisfied (try loop-unrolling to a source code without
>> loop), some of these pass may not affect the final result. How to know
>> which pass affect and which one is ignored? Does Llvm have this kind
>> of statistic? Thanks.
>
> One option is to use the -stats option with opt and hope that a  
> transform keeps statistics on how many transforms it makes.   
> However, this approach is fragile because an arbitrary LLVM pass may  
> not record any statistics on what it changes.
>
> Another approach is to use the -debug-pass=details option in opt.  I  
> believe it will tell you when a pass has modified the code and when  
> it has not.  That said, some transform passes may tell the  
> PassManager that they've modified the program when, in fact, they  
> haven't simply because it's too much programming work to track,  
> within the pass, whether it has modified anything.
>
> A third option might be to write a pass that somehow records the  
> current state of the bitcode and compares it to the state it saw  
> when it last executed.  You could then run this pass in between  
> every other pass to detect cases where the module does not change.
>
> So, there are some ways to do it, but only the third option (the  
> most time-consuming to do) looks fool-proof.
>
> -- John T.
>
>> Best,
>>
>> Kecheng
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>