Like many other compilers design, Clang compiler has three phase:<\/p>\n
- \n
- The front end that parses source code, checking it for errors, and builds a language-specific Abstract Syntax Tree (AST) to represent the input code.<\/li>\n
- The optimizer: its goal is to do some optimization on the AST generated by the front end.<\/li>\n
- The back end : that generate the final code to be executed by the machine, it depends of the target.<\/li>\n<\/ul>\n
![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/latfig1.gif?w=595\" "\\"latfig1\\"")
<\/a><\/p>\nWhat the difference between Clang and the other compilers?<\/strong><\/p>\n
The most important difference of its design is that Clang is based on LLVM , the idea behind LLVM is to use LLVM Intermediate Representation (IR), it\u2019s like the bytecode for java.
\nLLVM 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.<\/p>\nWith this design we can reuse a big part of the compiler to create other compilers, you can for example just change the front end part to treat other languages.<\/p>\n
![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/latfig2.gif?w=595\" "\\"latfig2\\"")
<\/a><\/p>\nI- Front End:<\/strong><\/p>\n
Clang is designed to be modular and each compilation phase is done by a specific\u00a0\u00a0module, Here are some projects implied in the front end phase:<\/p>\n
![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/llvm1.png?w=595\" "\\"llvm1\\"")
<\/a><\/p>\nAs any front end parser we need a lexer and a semantic analysis. The Clang front end could be executed by passing the -cc1 argument.\u00a0It\u00a0has several features like the AST generation:<\/p>\n
clang -cc1 -ast-dump test.c<\/p><\/blockquote>\n
This command line is treated by the cc1_main function,\u00a0here\u2019s the sequence of some interesting methods executed<\/p>\n
![\"clang11\"](\"http:\/\/www.codergears.com\/Blog\/wp-content\/uploads\/clang111.png\")
<\/a><\/p>\nThe method ExecuteAction has a parameter of type \u00a0FrontEndAction , the goal is to specify which frond end action to execute.\u00a0The FrontEndction is abstract , we need to inherit from it to implement a concrete front end action.<\/p>\n
Let\u2019s discover all the front end actions implemented by Clang using\u00a0CQLinq<\/a>, for that we can search for all classes inheriting directly or indirectly from it.<\/p>\n
from t in Types\r\nlet depth0 = t.DepthOfDeriveFrom(\u201cclang.FrontendAction\u201d)\r\nwhere depth0 >= 0 orderby depth0\r\nselect new { t, depth0 }\r\n<\/pre>\n![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/llvm2.png?w=595\" "\\"llvm2\\"")
<\/a><\/p>\nMany front end actions are available, for example ASTDumpAction permits to generate the AST without creating the final executable. Almost all the front end actions inherits\u00a0from ASTFrontEndAction, which\u00a0means that they work with the generated AST.<\/p>\n
What\u2019s interesting with this design is \u00a0we can plug our custom FrontEndAction easily, we have just to implement a new one.<\/p>\n
How we can do some treatments on the AST?<\/strong><\/p>\n
Each ASTFrontEndAction create one or many ASTConsumer, the ASTConsumer class is an abstract class, and we have to implement our AST consumer for our specific needs.<\/p>\n
The FrontEndAction will invoke the AST consumer as specified by the following graph.<\/p>\n
![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/llvm5.png\" "\\"llvm5\\"")
<\/a><\/p>\nLet\u2019s search for all ASTConsumer classes using\u00a0CQLinq<\/a>:<\/p>\n
from t in Types\r\nlet depth0 = t.DepthOfDeriveFrom(\u201cclang.ASTConsumer\u201d)\r\nwhere depth0 == 1\r\nselect new { t, depth0 }\r\n<\/pre>\n![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/llvm41.png?w=595\" "\\"llvm4\\"")
<\/a><\/p>\nCodeGenerator is an example of the AST Consumer<\/strong><\/p>\n
As we specified before the power of LLVM is to work with IR, and to generate it we need to parse the AST. CodeGenerator is the class inheriting from ASTConsumer responsible of generating the IR, and what\u2019s interesting is that this treatment is isolated into another project named ClangCodeGen.<\/p>\n
Here are some classes implied in the LLVM IR generation:<\/p>\n
![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/llvm6.png\" "\\"llvm6\\"")
<\/a><\/p>\nII- Optimizer<\/strong><\/p>\n
To explain this phase I can\u2019t say better than Chris Lattner the father of LLVM in this\u00a0post<\/a>:<\/p>\n
\u201cTo 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:<\/em><\/p>\n
- \n
- Look for a pattern to be transformed.<\/li>\n
- Verify that the transformation is safe\/correct for the matched instance.<\/li>\n
- Do the transformation, updating the code.<\/li>\n<\/ul>\n
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).
\n<\/em><\/p>\nLet\u2019s discover the LLVMCore passes, for that we can search for classes inheriting from \u201cpass\u201d class<\/p>\n
from t in Types\r\nlet depth0 = t.DepthOfDeriveFrom(\u201cllvm.Pass\u201d)\r\nwhere t.ParentProject.Name==\u201dLLVMCore\u201d && depth0 >= 0 orderby depth0\r\nselect new { t, depth0 }\r\n<\/pre>\n![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/llvm7.png?w=595\" "\\"llvm7\\"")
<\/a><\/p>\nOf course many other passes exist in the other LLVM modules.<\/p>\n
III- BackEnd<\/strong><\/p>\n
Like other phases the backend responsible of generating the output for a specific target, in the case of Clang it\u2019s very modular, let\u2019s take as example LLVMX86Target the module generating for X86 target.<\/p>\n
Here\u2019s the graph showing all the modules concerned by generating the binaries for x86 target.<\/p>\n
![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/llvm8.png?w=595\" "\\"llvm8\\"")
<\/a><\/p>\nMany modules are involved in this phase, each on has it\u2019s specific responsibility, which enforces the cohesion and\u00a0encourages clean APIs and separation.\u00a0Therefore making it easier for developers to understand, since they only have to undertand small pieces of the big picture.<\/p>\n
Conclusion<\/strong><\/p>\n
The duo LLVM\/Clang is not just a C\/C++ compiler, it\u2019s also an infrastructure to build tools, it\u2019s easy to extend its behavior. Many tools are included out of the box in the LLVM\/Clang source code and many others could be found in the web.<\/p>\n
If you need a C\/C++ parser to build a tool, Clang is a very good candidate.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
It\u2019s proven that Clang is a mature compiler For C and C++ as GCC and Microsoft compilers, but what makes it so special is the fact that it\u2019s not just a compiler. It\u2019s also an infrastructure to build tools. Thanks to its\u00a0library based architecture which makes the reuse and integration of\u00a0new features more flexible\u00a0and easier … Continue reading “Quick overview of how Clang works internally”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-321","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts\/321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/comments?post=321"}],"version-history":[{"count":8,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts\/321\/revisions"}],"predecessor-version":[{"id":379,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts\/321\/revisions\/379"}],"wp:attachment":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/media?parent=321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/categories?post=321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/tags?post=321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"http:\/\/cppdepend.files.wordpress.com\/2012\/10\/latfig1.gif\" "\\"latfig1\\"")
<\/a><\/p>\n