GCC (GNU Compiler Collection) and Clang are two of the most prominent C++ compilers in the world of software development. Each has a unique design philosophy and architecture that caters to different needs and preferences. This article explores the fundamental design differences between GCC and Clang, highlighting how these differences impact their functionality, performance, and usability.
Architectural Design Differences
- Clang: Clang's design is highly modular. It consists of a series of well-defined libraries (front end, middle end, and back end) that can be used independently or together. This modularity makes Clang easily extensible and maintainable. LibClang also provides a stable C interface to the Clang libraries, facilitating the development of tools and IDE integrations.
- GCC: Historically, GCC was designed as a monolithic compiler with tightly coupled components. While it has become more modular over time, it is still less modular than Clang. GCC supports plugins, but its architecture makes it harder to extend compared to Clang's more flexible design.
Let's take a closer look at Clang's design to understand why its architecture makes it easier to add new features and plugins.
Clang Design
Like many other compiler designs, the Clang compiler has three phases:
- The front end parses source code, checks it for errors, and builds a language-specific Abstract Syntax Tree (AST) to represent the input code.
- The optimizer performs optimizations on the AST generated by the front end.
- The back end generates the final machine code for the target architecture.
What makes Clang different from other compilers?
The most important difference in its design is that Clang is based on LLVM. The idea behind LLVM is to use LLVM Intermediate Representation (IR); it’s like the bytecode for Java.
LLVM IR is designed to host mid-level analyses and transformations that you find in the optimizer section of a compiler. It was designed with many specific goals in mind, including supporting lightweight runtime optimizations, cross-function/interprocedural optimizations, whole program analysis, and aggressive restructuring transformations, etc. The most important aspect of it, though, is that it is itself defined as a first class language with well-defined semantics.
With this design, a large part of the compiler can be reused to create other compilers. For example, you can change only the front end to process other languages.
I - Front End
Clang is designed to be modular, and each compilation phase is done by a specific module. Here are some of the projects involved in the front-end phase:
As with any front-end parser, we need a lexer and semantic analysis. The Clang front end could be executed by passing the -cc1 argument. It provides several features, such as AST generation:
clang -cc1 -ast-dump test.c
This command is handled by the cc1_main function. Here is the sequence of some of the interesting methods that are executed:
The method ExecuteAction has a parameter of type FrontEndAction; the goal is to specify which front end action to execute. The FrontEndAction is an abstract class, and we need to inherit from it to implement a concrete front end action.
Let’s discover all the front end actions implemented by Clang using CQLinq, for that we can search for all classes inheriting directly or indirectly from it.
from t in Types
let depth0 = t.DepthOfDeriveFrom(“clang.FrontendAction”)
where depth0 >= 0 orderby depth0
select new { t, depth0 }
Many front-end actions are available. For example, ASTDumpAction generates the AST without creating the final executable. Almost all the front end actions inherit from ASTFrontEndAction, which means that they work with the generated AST.
What's interesting about this design is that we can easily plug in a custom FrontEndAction; we simply need to implement a new one.
How can we perform some processing on the AST?
Each ASTFrontEndAction creates one or more ASTConsumer instances. The ASTConsumer class is an abstract class, and we have to implement our own AST consumer for our specific needs.
The FrontEndAction will invoke the AST consumer as specified by the following dependency graph.
Let’s search for all ASTConsumer classes using CQLinq:
from t in Types
let depth0 = t.DepthOfDeriveFrom(“clang.ASTConsumer”)
where depth0 == 1
select new { t, depth0 }
CodeGenerator is an example of an AST consumer. As mentioned earlier, one of LLVM’s strengths is its use of IR, and generating it requires parsing the AST. CodeGenerator is the class inheriting from ASTConsumer responsible for generating the IR, and what’s interesting is that this treatment is isolated into another project named ClangCodeGen.
Here are some of the classes involved in LLVM IR generation:
II - Optimizer
To explain this phase, I can’t say it better than Chris Lattner, the father of LLVM, in this post:
“To give some intuition for how optimizations work, it is useful to walk through some examples. There are lots of different kinds of compiler optimizations, so it is hard to provide a recipe for how to solve an arbitrary problem. That said, most optimizations follow a simple three-part structure:
- Look for a pattern to be transformed.
- Verify that the transformation is safe/correct for the matched instance.
- Do the transformation, updating the code.
The optimizer reads LLVM IR in, chews on it a bit, then emits LLVM IR, which hopefully will execute faster. In LLVM (as in many other compilers) the optimizer is organized as a pipeline of distinct optimization passes each of which is run on the input and has a chance to do something. Common examples of passes are the inliner (which substitutes the body of a function into call sites), expression reassociation, loop invariant code motion, etc. Depending on the optimization level, different passes are run: for example at -O0 (no optimization) the Clang compiler runs no passes, at -O3 it runs a series of 67 passes in its optimizer (as of LLVM 2.8).
Let’s explore the LLVMCore passes by searching for classes that inherit from the “pass” class.
from t in Types
let depth0 = t.DepthOfDeriveFrom(“llvm.Pass”)
where t.ParentProject.Name==”LLVMCore” && depth0 >= 0 orderby depth0
select new { t, depth0 }
Of course, many other passes exist in other LLVM modules.
III - BackEnd
Like the other phases, the backend is responsible for generating the output for a specific target. In Clang's case, this phase is highly modular. Take LLVMX86Target, for example, which generates code for the x86 target.
Here’s a graph showing all the modules involved in generating binaries for the x86 target.
Many modules are involved in this phase, each with a specific responsibility. This promotes cohesion, clean APIs, and separation of concerns, making the system easier for developers to understand because they can focus on small pieces of the bigger picture.
Fazit
The duo LLVM/Clang is not just a C/C++ compiler; it’s also an infrastructure to build tools, and it’s easy to extend its behavior. Many tools are included out of the box in the LLVM/Clang source code, and many others can be found on the web.
If you need a C/C++ parser to build a tool, Clang is a very good candidate.