a whirlwind tour of the llvm optimizer

The LLVM Project Blog

LLVM Project News and Details from the Trenches

The 2023 EuroLLVM Developers' Meeting Program

The LLVM Foundation is excited to announce the 2023 EuroLLVM Developers' Meeting program! Early bird registration ends April 10th.

• Order out of Chaos, The LLVM Release Process. - Tobias Hieta
• “-fbounds-safety”: Enforcing bounds safety for production C code - Yeoul Na

Technical Talks:

• An example of data flow analysis in MLIR - Tom Eccles
• MLIR-based offline memory planning and other graph-level optimizations for xcore.ai - Deepak Panickal
• A Rusty CHERI: The path to hardware capabilities in Rust - Lewis Revill
• Extending the AArch32 JITLink backend - Stefan Gränitz
• Using MLIR to Optimize Basic Linear Algebraic Subprograms - Steven Varoumas
• Buddy Compiler: An MLIR-based Compilation Framework for Deep Learning Co-design - Hongbin Zhang
• MachineScheduler - fine grain resource allocation using resource intervals. - Francesco Petrogalli
• Inliner in MLIR - Javed Absar
• How to use llvm-debuginfo-analyzer tool. - Carlos Alberto Enciso
• Practical Global Merge Function with ThinLTO - Kyungwoo Lee
• Prototyping MLIR in Python - Sasha Lopoukhine, Mathieu Fehr
• Extensible and Composable Dataflow Analysis in MLIR - Jeff Niu
• What would it take to remove debug intrinsics? - Jeremy Morse
• Compiling Ruby (with MLIR) - Alex Denisov
• What’s new in MLIR? - Mehdi Amini
• Structured Bindings and How to Analyze Them - Domján Dániel
• MLIR Dialect Design and Composition for Front-End Compilers - Jeff Niu
• ML-LLVM-Tools: Towards Seamless Integration of Machine Learning in Compiler Optimizations - S. VenkataKeerthy, Siddharth Jain, Umesh Kalvakuntla
• Optimizing the Linux Kernel with LLVM BOLT - Maksim Panchenko
• mlir-meminfo : A Memory Model for MLIR - Kunwar Grover,Arjun Pitchanathan
• Developing BOLT pass - Amir Ayupov
• A whirlwind tour of the LLVM optimizer - Nikita Popov
• Tutorial: Controllable Transformations in MLIR - Alex Zinenko
• GlobalISel by example - Alex Bradbury

Quick Talks:

• Iterative Compilation - Give the compiler a second chance - Ziv Ben Zion
• Another level of indirection - Compiler Fallback of load/store into gather/scatter enhance compiler robustness by overcoming analysis and hardware limitations - Omer Aviram
• Switch per function in LLVM - Tomer Nissim Schneider
• Tensor Evolution - An ML Graph Optimization Technique - Javed Absar,Muthu Baskaran
• ML-on-CPU: should vectorization happen in the LLVM backend or higher up the stack? - Elen Kalda
• CORE-V LLVM: Adding eight vendor extensions to standard RISC-V LLVM - Charlie Keaney,Chunyu Liao (廖春玉),Lewis Revill
• Advanced Bug Reports: Choose Your Own Adventure - Arseniy Zaostrovnykh
• Multiple-Entry, Multiple-Exit MLIR Regions - Jeff Niu
• Target-Independent Integer Arithmetic - Jeff Niu
• Improving Vectorization for Loops with Control Flow - Ashutosh Nema
• How to run the LLVM-Test Suite on GPUs and what you’ll find - Johannes Doerfert
• OpenMP as GPU Kernel Language - Johannes Doerfert

Lightning Talks:

• LLVM IR as an Embedded Domain-Specific Language - Nikita Baksalyar
• Using MLIR for Dalvik Bytecode Analysis - Eduardo Blázquez
• High school student’s experience with Clang - Yubo Hui
• Spot the Difference with LLVM-FLOW: an open-source interactive visualization tool for comparing IR CFGs - Jinmyoung Lee
• Leveraging MLIR for Better SYCL Compilation - Victor Lomüller
• Arm/AArch64 Embedded Development with LLD : What’s New - Amilendra Kodithuwakku
• Using automated tests to tune the -Og pipeline - Stephen Livermore-Tozer
• Buddy-CAAS: Compiler As A Service for MLIR - Hongbin Zhang
• llvm-buildmark - observations, tips, and tricks on reducing LLVM build times - Alex Bradbury
• Lock Coarsening optimizations for loops in Java - Anna Thomas

Student Technical Talks

• Cost Modelling for Register Allocation and Beyond - Aiden Grossman
• A Template-Based Code Generation Approach for MLIR - Florian Drescher
• MLIR Query Tool for easier exploration of the IR - Devajith Valaparambil Sreeramaswamy
• mlirSynth: Synthesis of Domain-Specific Programs in MLIR - Alexander Brauckmann
• Image Processing Ops as first class citizens in MLIR: write once, vectorise everywhere! - Prathamesh Tagore,Hongbin Zhang
• Using the Clang data-flow framework for null-pointer analysis - Viktor Cseh
• Fast and Vectorized Pivot Function for MLIR Presburger Library - Qi
• RISC-V Vector Extension Support in MLIR: Motivation, Abstraction, and Application - Hongbin Zhang
• Automatic Translation of C++ to Rust - Henrique Preto
• A sustainable approach to have vector predication in the Loop Vectorizer - Lorenzo Albano
• Performance Analysis of Undefined Behavior Optimizations - Lucian Popescu
• Static Analysis for C++ Rust-Like Lifetime Annotations - Susana Monteiro
• Forcefully Embedding MLIR into Python - George Mitenkov

We would also like to thank the program committee:

Kristof Beyls ( Chair ), Alex Bradbury, Alex Denisov, Anupama Chandrasekhar, David Spickett, Florian Hahn, Gabor Horvath,Hans Wennborg, Jakub Kuderski, Jonathan Springer, Jubi Taneja, Mehdi Amini, Michal Paczkowski, Min-Yih Hsu, Nadav Rotem, Paul Kirth, Petr Hosek, Quentin Colombet, Renato Golin, Stephen Neuendorffer, Timothy Harvey,and Tobias Grosser.

Register today to attend the 2023 EuroLLVM Developers' Meeting in Glasgow, Scotland.

• Interactive programming in C++ internships — LLVM Blog Post
• Adding a new target/object backend to LLVM JITLink

• Enter Our Giveaways
• PragProg Errata

A whirlwind tour of the LLVM optimizer

A whirlwind tour of the LLVM optimizer. A whirlwind tour of the LLVM optimizer Nikita Popov @ EuroLLVM 2023 Agenda ● High-level overview of the middle-end optimization pipeline ● Brief description o…

Read in full here:

This thread was posted by one of our members via one of our news source trackers.

Corresponding tweet for this thread:

Share link for this tweet.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

A superoptimizer for LLVM IR

google/souper

Folders and files, repository files navigation.

Souper is a superoptimizer for LLVM IR. It uses an SMT solver to help identify missing peephole optimizations in LLVM's midend optimizers.

The architecture and concepts of Souper are described in Souper: A synthesizing superoptimizer .

Requirements

Souper should work on any reasonably modern Linux or OS X machine.

You will need a reasonably modern compiler toolchain. LLVM has instructions on how to get one for Linux: http://llvm.org/docs/GettingStarted.html#getting-a-modern-host-c-toolchain

You will also need CMake to build Souper and its dependencies, and the zstd library from your package manager or from Homebrew.

Building Souper

• Download and build dependencies:

$buildtype is optional; it defaults to Release and may be set to any LLVM build type. $extra_cmake_flags is optional. It is passed to CMake.

• Run CMake from a build directory:

Again, the build type is optional and defaults to Release. In any case it must match the build type used when compiling the dependencies.

Run 'make' from the build directory.

Optionally run 'make check' to run Souper's test suite. To run the test suite under Valgrind, run 'make check LIT_ARGS="-v --vg --vg-leak"' instead. By default the solver is also run under Valgrind. This can be disabled by by adding --vg-arg=--trace-children-skip=/path/to/solver to LIT_ARGS.

Note that GCC 4.8 and earlier have a bug in handling multiline string literals. You should build Souper using GCC 4.9+ or Clang.

Using Souper

After following the above instructions, you will have a Souper executable in /path/to/souper-build/souper and a Clang executable in /path/to/souper/third_party/llvm/$buildtype/bin/clang. You can use the Clang executable to create an LLVM bitcode file like this:

For example:

Souper will extract SMT queries from the bitcode file and pass them to a solver. Unsatisfiable queries (which represent missed optimization opportunities) will cause Souper to print its internal representation of the optimizable expression along with the shorter expression that refines the original one.

Alternatively, you may immediately let Souper modify the bitcode and let it apply the missed optimization opportunities by using the Souper llvm opt pass. When loaded the pass will automatically register itself to run after LLVM's regular peephole optimizations.

Or to run the pass on its own:

Or use the drop-in compiler replacements sclang and sclang++:

Compilation using Souper can be sped up by caching queries. By default, Souper uses a non-persistent RAM-based cache. The -souper-external-cache flag causes Souper to cache its queries in a Redis database. For this to work, Redis >= 1.2.0 must be installed on the machine where you are running Souper and a Redis server must be listening on the default port (6379).

sclang uses external caching by default since this often gives a substantial speedup for large compilations. This behavior may be disabled by setting the SOUPER_NO_EXTERNAL_CACHE environment variable. Souper's Redis cache does not yet have any support for versioning; you should stop Redis and delete its dump file any time Souper is upgraded.

Please note that although some of the authors are employed by Google, this is not an official Google product.

Code of conduct

Security policy, contributors 20.

• Python 3.2%

LLVM: The middle-end optimization pipeline

Compilers are classically split into three parts: The front end, the middle end and the back end. The front end is what deals with programming-language specific analysis, such as parsing, type checking, etc.

The middle end performs optimizations that are independent (to the degree that this is possible) from both the input language and the output target. Finally, the back end performs target-specific optimizations and emits machine code.

This separation is what saves everyone from reinventing the wheel. New programming languages only need to implement the frontend. New CPU architectures only need to implement the backend. And indeed, while there are many, many different language frontends, they nearly always rely on LLVM for the middle and backends:

In this article I want to discuss, at a very high level, how LLVM’s middle end optimization pipeline looks like.

The three optimization pipelines

There are three kinds of optimization pipelines: The default (non-LTO) pipeline, the ThinLTO pipeline and the FatLTO pipeline. The default pipeline works by separately optimizing each module, without any special knowledge about other modules (apart from function/global declarations). “Module” here corresponds to “one source file” in C/C++ and one “codegen unit” in Rust.

The LTO pipelines are split into a pre-link and a post-link optimization pipeline. After the pre-link pipeline, ThinLTO will perform some lightweight cross-module analysis, and in particular import certain functions from other modules to make them eligible for inlining. However, the post-link optimization again works on individual modules.

Finally, FatLTO will simply merge all modules together after the pre-link pipeline and then run the post-link pipeline on a single, huge module:

While LTO stands for “link-time optimization”, it is not necessarily performed by the linker. For example, rustc will usually perform it as part of the compiler. The important property of LTO is that is allows cross-module optimization.

LTO is also typically accompanied by a restricted list of symbols that need to be exported (i.e. externally accessible), while everything else can be internalized (i.e. become an internal implementation detail). This allows for whole program optimization (WPO).

The default optimization pipeline

The optimization pipelines are defined in PassBuilderPipelines and the default pipeline in particular is created by buildPerModuleDefaultPipeline() . I will mostly talk about the pipeline in terms of generalities, so take a look at that file if you want to inspect the precise pass ordering.

The pipeline consists of two parts: The module simplification and the module optimization pipelines.

The job of the simplification pipeline is to simplify and canonicalize the IR. The job of the optimization pipeline is to perform optimizations that may make the IR more complex or less canonical.

Examples of the latter are vectorization and runtime unrolling. These transforms will generally greatly increase IR size and make it harder to analyze, which is why it is important that they run in the late optimization pipeline.

Most other transforms are simplifications, including classics like SROA, CSE/GVN, LICM, instruction combining, etc. An interesting case is full unrolling, which, unlike runtime unrolling, is also part of the simplification pipeline, because it converts a loop into straight-line code, opening up additional simplification opportunities.

The LTO pipelines

The ThinLTO pipeline is where the simplification/optimization split really comes into action: The pre-link pipeline basically just runs the simplification part, while the post-link pipeline runs both simplification and optimization.

The key property of LTO optimization is that additional inlining may be performed in the post-link step. As such, it is important that optimizations that increase IR size or decrease canonicality are not performed during the pre-link phase.

For example, we do not want functions to get vectorized pre-link, because this might prevent them from being inlined and then simplified in more profitable ways.

For the same reason, some other minor adjustments to the pre-link phase are performed. For example, loop rotation will be suppressed if it would duplicate a call: That call might become inlinable post-link, which might render the duplication much more expensive than it would otherwise be.

Running the simplification pipeline over everything again post-link is not strictly necessary: Ideally, it would only be applied to functions where additional inlining actually happened. This is a possible optimization for the future.

As for the fat LTO pipeline … well, we don’t talk about the fat LTO pipeline. Its design is somewhere between non-sensical and non-existent. Fat LTO runs the module optimization pipeline pre-link (which is not a good idea for the same reasons as for ThinLTO), and the post-link pipeline is entirely home-grown and not based on the standard simplification/optimization pipelines.

The module simplification pipeline

Now that we have put things into context, let’s return to the module simplification pipeline, the core of which is the CGSCC inliner. CGSCC is short for call-graph strongly-connected components .

The basic idea is that if you have a call-graph consisting of callers and callees (callee = called function), you want to simplify the callees first, before you try to inline them into the callers (and then simplify those too). Simplifying callees before inlining makes the cost-modelling more accurate and reduces the amount of simplification that needs to be performed post-inlining.

This is what CGSCC passes do: They try to visit callees before callers. For cyclic (recursive) call-graphs, this is not possible, so they do the next best thing: Visit strongly-connected components of mutually recursive functions. There is no well-defined visitation order within one component, but at least we preserve the “callee before callers” property between components.

The CGSCC pipeline consists essentially of the inliner and the function simplification pipeline. In addition to that it contains a few other CGSCC passes, e.g. for argument promotion (argument-level SROA) and inferral of function attributes.

The key bit is that inlining and simplification are interleaved, so that after calls into a function have been inlined, it will be simplified before becoming an inlining candidate itself. (This is another failure of the fat LTO pipeline, which does not interleave inlining and simplification.)

Before the CGSCC inliner, the module simplification pipeline performs some early cleanup. In particular this involes running a SimplifyCFG+SROA+EarlyCSE sequence on all functions, followed by some module-level passes, such as optimization of globals and IPSCCP, which performs inter-procedural constant and range propagation. I believe the purpose of the early function cleanup is to prepare for these module passes, and to make sure that non-trivial SCCs receive at least basic cleanup prior to inlining.

The function simplification pipeline

The function simplification pipeline is the very core of the entire optimization pipeline. Unfortunately, this is also the point where it becomes hard to make high-level statements about its underlying design philosophy.

There is a saying that goes something like this (I couldn’t find any source for it, but I’m also pretty sure I didn’t invent it):

Optimization is a science, phase ordering is an art.

There isn’t really a way to determine the correct ordering of optimization passes from first principles. It’s something that comes from experience, and incremental adjustments to handle this or that test case. In most cases, nobody will be able to tell you why a pass is scheduled in precisely the place it is.

The key constraint of phase ordering is compile-time. An easy solution to many phase ordering problems would be to just schedule a few extra pass runs, but this is rarely a worthwhile tradeoff. Fixing someone’s pet use case by scheduling an extra GVN run and thus making everyone pay an extra 5-10% compile-time is not a good idea.

A key part of compile-time reduction is analysis sharing. Passes that depend on the same expensive analysis will be scheduled as a group. For example, the jump threading and correlated value propagation passes are always scheduled as a pair, because they both depend on the expensive lazy value information analysis, which provides information on value ranges.

The function simplification pipeline contains two primary loop pipelines. The loop pipelines also work in an interleaved manner, where a sequence of loop passes is first applied to an inner-most loop, and then outer loops.

The primary distinction between the two loop pipelines is that the former uses and preserves MemorySSA (primarily to drive loop invariant code motion), while the latter does not. Once again, this is driven by analysis-sharing concerns.

In summary, this is roughly how LLVM’s optimization pipeline looks like:

The cute “backend” box hides another optimization pipeline that I have ignored entirely here. Maybe I’ll talk about it some other time.

Finally, it’s worth mentioning that the optimization pipeline has a number of extension points where additional passes can be inserted either by the frontend, the backend or plugins. For example, frontends will usually add sanitizer passes using this mechanism.

It is also possible to have an entirely custom optimization pipeline. The standard pipeline is mostly tuned for Clang, but also works well for rustc, and I don’t think rustc would benefit substantially from a custom pipeline. However, when it comes to more exotic languages (e.g. Java and other GC languages) a custom optimization pipeline may be necessary.

A whirlwind tour of the LLVM optimizer

todo list of learning llvm optimization passes.

最近在 Nikita Popov 在 EuroLLVM 2023 进行了题为 “A whirlwind tour of the LLVM optimizer” 的分享，目前只开放了 slide，youtube 上还没有更新视频。

我以前也阅读过一些 LLVM passes 的源码，但是感觉只是为了阅读而阅读，后来就慢慢地停下来了。在看到 Nikita Popov 的分享 slide 后，决心把 slide 中提到的所有 optimization passes 研究透，于是开坑本文作为记录。

Optimization passes todo list :

SSA Construction

Control-Flow Optimization

SimplifyCFG

JumpThreading

Instruction Combining(Peephole Optimization)

InstCombine

CorrelatedValuePropagation

Redundancy Elimination

Memory Optimizations

Loop Optimization

IndVarSimplify

Vectorization

LoopVectorize

SLPVectorize

Inter-Procedural Optimization (IPO)

FunctionAttrs

• LLVM Home  | 
• Documentation »
• Reference »
• LLVM Command Guide »

Documentation

• Getting Started/Tutorials
• User Guides

Getting Involved

• Contributing to LLVM
• Submitting Bug Reports
• Mailing Lists
• Meetups and Social Events

Additional Links

• Publications
• Github Repository
• Show Source

Quick search

Opt - llvm optimizer ¶.

opt [ options ] [ filename ]

DESCRIPTION ¶

The opt command is the modular LLVM optimizer and analyzer. It takes LLVM source files as input, runs the specified optimizations or analyses on it, and then outputs the optimized file. The optimizations available via opt depend upon what libraries were linked into it as well as any additional libraries that have been loaded with the -load option. Use the -help option to determine what optimizations you can use.

If filename is omitted from the command line or is “ - “, opt reads its input from standard input. Inputs can be in either the LLVM assembly language format ( .ll ) or the LLVM bitcode format ( .bc ).

If an output filename is not specified with the -o option, opt writes its output to the standard output.

Enable binary output on terminals. Normally, opt will refuse to write raw bitcode output if the output stream is a terminal. With this option, opt will write raw bitcode regardless of the output device.

Print a summary of command line options.

Specify the output filename.

Write output in LLVM intermediate language (instead of bitcode).

opt provides the ability to run any of LLVM’s optimization or analysis passes in any order. The -help option lists all the passes available. The order in which the options occur on the command line are the order in which they are executed (within pass constraints).

This option causes opt to strip debug information from the module before applying other optimizations. It is essentially the same as -strip but it ensures that stripping of debug information is done first.

This option causes opt to add a verify pass after every pass otherwise specified on the command line (including -verify ). This is useful for cases where it is suspected that a pass is creating an invalid module but it is not clear which pass is doing it.

Print statistics.

Record the amount of time needed for each pass and print it to standard error.

If this is a debug build, this option will enable debug printouts from passes which use the LLVM_DEBUG() macro. See the LLVM Programmer’s Manual , section #DEBUG for more information.

Load the dynamic object plugin . This object should register new optimization or analysis passes. Once loaded, the object will add new command line options to enable various optimizations or analyses. To see the new complete list of optimizations, use the -help and -load options together. For example:

Print all available passes and exit.

EXIT STATUS ¶

If opt succeeds, it will exit with 0. Otherwise, if an error occurs, it will exit with a non-zero value.