[llvm-dev] Effectiveness of llvm optimisation passes

Haidl, Michael via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 21 22:14:58 PDT 2017


Craig was faster on the optnone flag (if you are using Clang 5 and above).
However, I observed that some of the opt passes ignore the optnone in 
some cases, e.g., -breack-crit-edge.
You can use the -stats flag from opt to get a list of statistics what a 
particular pass did (if it collects statistics of course).

On 22.09.2017 07:11, Craig Topper via llvm-dev wrote:
> Have -O0 on your clang command line causes all functions to get marked 
> with an 'optnone' attribute that prevents opt from being able to 
> optimize them later. You should also add "-Xclang -disable-O0-optnone" 
> to your command line.
> 
> ~Craig
> 
> On Thu, Sep 21, 2017 at 10:04 PM, Yi Lin via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>     Hi all,
> 
>     I am trying to understand the effectiveness of various llvm
>     optimisations when a language targets llvm (or C) as its backend.
> 
>     The following is my approach (please correct me if I did anything
>     wrong):
> 
>     I am trying to explicitly control the optimisations passes in llvm.
>     I disable optimisation in clang, but instead emit unoptimized llvm
>     IR, and use opt to optimise that. These are what I do:
> 
>     * clang -O0 -S -mllvm -disable-llvm-optzns -emit-llvm
>     -momit-leaf-frame-pointer a.c -o a.ll
>     * opt -(PASSES) a.ll -o a.bc
>     * llc a.bc -filetype=obj -o a.o
> 
>     To evaluate the effectiveness of optimisation passes, I started with
>     an 'add-one-in' approach. The baseline is no optimisations passes,
>     and I iterate through all the O1 passes and explicitly allow one
>     pass for each run. I didnt try understand those passes so it is a
>     black box test. This will show how effective each single
>     optimisation is (ignore correlation of passes). This can be
>     iterative, e.g. identify the most effecitve pass, and always enable
>     it, and then 'add-one-in' for the rest passes. I also plan to take a
>     'leave-one-out' approach as well, in which the baseline is all
>     optimisations enabled, and one pass will be disabled at a time.
> 
>     Here is the result for the 'add-one-in' approach on some micro
>     benchmarks:
> 
>     https://drive.google.com/drive/folders/0B9EKhGby1cv9YktaS3NxUVg2Zk0
>     <https://drive.google.com/drive/folders/0B9EKhGby1cv9YktaS3NxUVg2Zk0>
> 
>     The result seems a bit surprising. A few passes, such as licm, sroa,
>     instcombine and mem2reg, seem to deliver a very close performance as
>     O1 (which includes all the passes). Figure 7 is an example. If my
>     methodology is correct, then my guess is those optimisations may
>     require some common internal passes, which actually deliver most of
>     the improvements. I am wondering if this is true.
> 
>     Any suggestion or critiques are welcome.
> 
>     Thanks,
>     Yi
> 
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 


More information about the llvm-dev mailing list