[LLVMdev] pass statistic

kecheng at cecs.pdx.edu kecheng at cecs.pdx.edu
Sun Mar 13 11:40:23 PDT 2011


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
>
>







More information about the llvm-dev mailing list