llvm.org GIT mirror llvm / 160dae7
Add an OCaml tutorial page 8 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122650 91177308-0d34-0410-b5e6-96231b3b80d8 Erick Tryzelaar 8 years ago
2 changed file(s) with 366 addition(s) and 1 deletion(s). Raw diff Collapse all Expand all
2929
  • Full Code Listing
  • 3030
    3131
    32
  • Chapter 8: Conclusion and other useful LLVM
  • 32
  • Chapter 8: Conclusion and other useful LLVM
  • 3333 tidbits
    3434
    3535
    0
    1 "http://www.w3.org/TR/html4/strict.dtd">
    2
    3
    4
    5 Kaleidoscope: Conclusion and other useful LLVM tidbits
    6
    7
    8
    9
    10
    11
    12
    13
    Kaleidoscope: Conclusion and other useful LLVM
    14 tidbits
    15
    16
    17
  • Up to Tutorial Index
  • 18
  • Chapter 8
  • 19
    20
  • Tutorial Conclusion
  • 21
  • Properties of LLVM IR
  • 22
    23
  • Target Independence
  • 24
  • Safety Guarantees
  • 25
  • Language-Specific Optimizations
  • 26
    27
    28
  • Tips and Tricks
  • 29
    30
  • Implementing portable
  • 31 offsetof/sizeof
    32
  • Garbage Collected Stack Frames
  • 33
    34
    35
    36
    37
    38
    39
    40
    41

    Written by Chris Lattner

    42
    43
    44
    45
    46
    47
    48
    49
    50

    Welcome to the the final chapter of the "Implementing a

    51 language with LLVM" tutorial. In the course of this tutorial, we have grown
    52 our little Kaleidoscope language from being a useless toy, to being a
    53 semi-interesting (but probably still useless) toy. :)

    54
    55

    It is interesting to see how far we've come, and how little code it has

    56 taken. We built the entire lexer, parser, AST, code generator, and an
    57 interactive run-loop (with a JIT!) by-hand in under 700 lines of
    58 (non-comment/non-blank) code.

    59
    60

    Our little language supports a couple of interesting features: it supports

    61 user defined binary and unary operators, it uses JIT compilation for immediate
    62 evaluation, and it supports a few control flow constructs with SSA construction.
    63

    64
    65

    Part of the idea of this tutorial was to show you how easy and fun it can be

    66 to define, build, and play with languages. Building a compiler need not be a
    67 scary or mystical process! Now that you've seen some of the basics, I strongly
    68 encourage you to take the code and hack on it. For example, try adding:

    69
    70
    71
  • global variables - While global variables have questional value in
  • 72 modern software engineering, they are often useful when putting together quick
    73 little hacks like the Kaleidoscope compiler itself. Fortunately, our current
    74 setup makes it very easy to add global variables: just have value lookup check
    75 to see if an unresolved variable is in the global variable symbol table before
    76 rejecting it. To create a new global variable, make an instance of the LLVM
    77 GlobalVariable class.
    78
    79
  • typed variables - Kaleidoscope currently only supports variables of
  • 80 type double. This gives the language a very nice elegance, because only
    81 supporting one type means that you never have to specify types. Different
    82 languages have different ways of handling this. The easiest way is to require
    83 the user to specify types for every variable definition, and record the type
    84 of the variable in the symbol table along with its Value*.
    85
    86
  • arrays, structs, vectors, etc - Once you add types, you can start
  • 87 extending the type system in all sorts of interesting ways. Simple arrays are
    88 very easy and are quite useful for many different applications. Adding them is
    89 mostly an exercise in learning how the LLVM
    90 href="../LangRef.html#i_getelementptr">getelementptr instruction works: it
    91 is so nifty/unconventional, it
    92 href="../GetElementPtr.html">has its own FAQ! If you add support
    93 for recursive types (e.g. linked lists), make sure to read the
    94 href="../ProgrammersManual.html#TypeResolve">section in the LLVM
    95 Programmer's Manual that describes how to construct them.
    96
    97
  • standard runtime - Our current language allows the user to access
  • 98 arbitrary external functions, and we use it for things like "printd" and
    99 "putchard". As you extend the language to add higher-level constructs, often
    100 these constructs make the most sense if they are lowered to calls into a
    101 language-supplied runtime. For example, if you add hash tables to the language,
    102 it would probably make sense to add the routines to a runtime, instead of
    103 inlining them all the way.
    104
    105
  • memory management - Currently we can only access the stack in
  • 106 Kaleidoscope. It would also be useful to be able to allocate heap memory,
    107 either with calls to the standard libc malloc/free interface or with a garbage
    108 collector. If you would like to use garbage collection, note that LLVM fully
    109 supports Accurate Garbage Collection
    110 including algorithms that move objects and need to scan/update the stack.
    111
    112
  • debugger support - LLVM supports generation of
  • 113 href="../SourceLevelDebugging.html">DWARF Debug info which is understood by
    114 common debuggers like GDB. Adding support for debug info is fairly
    115 straightforward. The best way to understand it is to compile some C/C++ code
    116 with "llvm-gcc -g -O0" and taking a look at what it produces.
    117
    118
  • exception handling support - LLVM supports generation of
  • 119 href="../ExceptionHandling.html">zero cost exceptions which interoperate
    120 with code compiled in other languages. You could also generate code by
    121 implicitly making every function return an error value and checking it. You
    122 could also make explicit use of setjmp/longjmp. There are many different ways
    123 to go here.
    124
    125
  • object orientation, generics, database access, complex numbers,
  • 126 geometric programming, ... - Really, there is
    127 no end of crazy features that you can add to the language.
    128
    129
  • unusual domains - We've been talking about applying LLVM to a domain
  • 130 that many people are interested in: building a compiler for a specific language.
    131 However, there are many other domains that can use compiler technology that are
    132 not typically considered. For example, LLVM has been used to implement OpenGL
    133 graphics acceleration, translate C++ code to ActionScript, and many other
    134 cute and clever things. Maybe you will be the first to JIT compile a regular
    135 expression interpreter into native code with LLVM?
    136
    137
    138
    139

    140 Have fun - try doing something crazy and unusual. Building a language like
    141 everyone else always has, is much less fun than trying something a little crazy
    142 or off the wall and seeing how it turns out. If you get stuck or want to talk
    143 about it, feel free to email the
    144 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev mailing
    145 list: it has lots of people who are interested in languages and are often
    146 willing to help out.
    147

    148
    149

    Before we end this tutorial, I want to talk about some "tips and tricks" for generating

    150 LLVM IR. These are some of the more subtle things that may not be obvious, but
    151 are very useful if you want to take advantage of LLVM's capabilities.

    152
    153
    154
    155
    156
    157 IR
    158
    159
    160
    161
    162

    We have a couple common questions about code in the LLVM IR form - lets just

    163 get these out of the way right now, shall we?

    164
    165
    166
    167
    168
    169 Independence
    170
    171
    172
    173
    174

    Kaleidoscope is an example of a "portable language": any program written in

    175 Kaleidoscope will work the same way on any target that it runs on. Many other
    176 languages have this property, e.g. lisp, java, haskell, javascript, python, etc
    177 (note that while these languages are portable, not all their libraries are).

    178
    179

    One nice aspect of LLVM is that it is often capable of preserving target

    180 independence in the IR: you can take the LLVM IR for a Kaleidoscope-compiled
    181 program and run it on any target that LLVM supports, even emitting C code and
    182 compiling that on targets that LLVM doesn't support natively. You can trivially
    183 tell that the Kaleidoscope compiler generates target-independent code because it
    184 never queries for any target-specific information when generating code.

    185
    186

    The fact that LLVM provides a compact, target-independent, representation for

    187 code gets a lot of people excited. Unfortunately, these people are usually
    188 thinking about C or a language from the C family when they are asking questions
    189 about language portability. I say "unfortunately", because there is really no
    190 way to make (fully general) C code portable, other than shipping the source code
    191 around (and of course, C source code is not actually portable in general
    192 either - ever port a really old application from 32- to 64-bits?).

    193
    194

    The problem with C (again, in its full generality) is that it is heavily

    195 laden with target specific assumptions. As one simple example, the preprocessor
    196 often destructively removes target-independence from the code when it processes
    197 the input text:

    198
    199
    200
    
                      
                    
    201 #ifdef __i386__
    202 int X = 1;
    203 #else
    204 int X = 42;
    205 #endif
    206
    207
    208
    209

    While it is possible to engineer more and more complex solutions to problems

    210 like this, it cannot be solved in full generality in a way that is better than shipping
    211 the actual source code.

    212
    213

    That said, there are interesting subsets of C that can be made portable. If

    214 you are willing to fix primitive types to a fixed size (say int = 32-bits,
    215 and long = 64-bits), don't care about ABI compatibility with existing binaries,
    216 and are willing to give up some other minor features, you can have portable
    217 code. This can make sense for specialized domains such as an
    218 in-kernel language.

    219
    220
    221
    222
    223
    224
    225
    226
    227
    228

    Many of the languages above are also "safe" languages: it is impossible for

    229 a program written in Java to corrupt its address space and crash the process
    230 (assuming the JVM has no bugs).
    231 Safety is an interesting property that requires a combination of language
    232 design, runtime support, and often operating system support.

    233
    234

    It is certainly possible to implement a safe language in LLVM, but LLVM IR

    235 does not itself guarantee safety. The LLVM IR allows unsafe pointer casts,
    236 use after free bugs, buffer over-runs, and a variety of other problems. Safety
    237 needs to be implemented as a layer on top of LLVM and, conveniently, several
    238 groups have investigated this. Ask on the
    239 href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev mailing
    240 list if you are interested in more details.

    241
    242
    243
    244
    245
    246 Optimizations
    247
    248
    249
    250
    251

    One thing about LLVM that turns off many people is that it does not solve all

    252 the world's problems in one system (sorry 'world hunger', someone else will have
    253 to solve you some other day). One specific complaint is that people perceive
    254 LLVM as being incapable of performing high-level language-specific optimization:
    255 LLVM "loses too much information".

    256
    257

    Unfortunately, this is really not the place to give you a full and unified

    258 version of "Chris Lattner's theory of compiler design". Instead, I'll make a
    259 few observations:

    260
    261

    First, you're right that LLVM does lose information. For example, as of this

    262 writing, there is no way to distinguish in the LLVM IR whether an SSA-value came
    263 from a C "int" or a C "long" on an ILP32 machine (other than debug info). Both
    264 get compiled down to an 'i32' value and the information about what it came from
    265 is lost. The more general issue here, is that the LLVM type system uses
    266 "structural equivalence" instead of "name equivalence". Another place this
    267 surprises people is if you have two types in a high-level language that have the
    268 same structure (e.g. two different structs that have a single int field): these
    269 types will compile down into a single LLVM type and it will be impossible to
    270 tell what it came from.

    271
    272

    Second, while LLVM does lose information, LLVM is not a fixed target: we

    273 continue to enhance and improve it in many different ways. In addition to
    274 adding new features (LLVM did not always support exceptions or debug info), we
    275 also extend the IR to capture important information for optimization (e.g.
    276 whether an argument is sign or zero extended, information about pointers
    277 aliasing, etc). Many of the enhancements are user-driven: people want LLVM to
    278 include some specific feature, so they go ahead and extend it.

    279
    280

    Third, it is possible and easy to add language-specific

    281 optimizations, and you have a number of choices in how to do it. As one trivial
    282 example, it is easy to add language-specific optimization passes that
    283 "know" things about code compiled for a language. In the case of the C family,
    284 there is an optimization pass that "knows" about the standard C library
    285 functions. If you call "exit(0)" in main(), it knows that it is safe to
    286 optimize that into "return 0;" because C specifies what the 'exit'
    287 function does.

    288
    289

    In addition to simple library knowledge, it is possible to embed a variety of

    290 other language-specific information into the LLVM IR. If you have a specific
    291 need and run into a wall, please bring the topic up on the llvmdev list. At the
    292 very worst, you can always treat LLVM as if it were a "dumb code generator" and
    293 implement the high-level optimizations you desire in your front-end, on the
    294 language-specific AST.
    295

    296
    297
    298
    299
    300
    301
    302
    303
    304
    305

    There is a variety of useful tips and tricks that you come to know after

    306 working on/with LLVM that aren't obvious at first glance. Instead of letting
    307 everyone rediscover them, this section talks about some of these issues.

    308
    309
    310
    311
    312
    313 offsetof/sizeof
    314
    315
    316
    317
    318

    One interesting thing that comes up, if you are trying to keep the code

    319 generated by your compiler "target independent", is that you often need to know
    320 the size of some LLVM type or the offset of some field in an llvm structure.
    321 For example, you might need to pass the size of a type into a function that
    322 allocates memory.

    323
    324

    Unfortunately, this can vary widely across targets: for example the width of

    325 a pointer is trivially target-specific. However, there is a
    326 href="http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt">clever
    327 way to use the getelementptr instruction that allows you to compute this
    328 in a portable way.

    329
    330
    331
    332
    333
    334 Stack Frames
    335
    336
    337
    338
    339

    Some languages want to explicitly manage their stack frames, often so that

    340 they are garbage collected or to allow easy implementation of closures. There
    341 are often better ways to implement these features than explicit stack frames,
    342 but
    343 href="http://nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt">LLVM
    344 does support them, if you want. It requires your front-end to convert the
    345 code into
    346 href="http://en.wikipedia.org/wiki/Continuation-passing_style">Continuation
    347 Passing Style and the use of tail calls (which LLVM also supports).

    348
    349
    350
    351
    352
    353
    354
    355 src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!">
    356
    357 src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!">
    358
    359 Chris Lattner
    360 The LLVM Compiler Infrastructure
    361 Last modified: $Date$
    362
    363
    364