docs/FAQ.rst

   1 ================================
   2 Frequently Asked Questions (FAQ)
   3 ================================
   4
   5 .. contents::
   6    :local:
   7
   8
   9 License
  10 =======
  11
  12 Can I modify LLVM source code and redistribute the modified source?
  13 -------------------------------------------------------------------
  14 Yes.  The modified source distribution must retain the copyright notice and
  15 follow the conditions listed in the `LLVM license
  16 <http://llvm.org/svn/llvm-project/llvm/trunk/LICENSE.TXT>`_.
  17
  18
  19 Can I modify the LLVM source code and redistribute binaries or other tools based on it, without redistributing the source?
  20 --------------------------------------------------------------------------------------------------------------------------
  21 Yes. This is why we distribute LLVM under a less restrictive license than GPL,
  22 as explained in the first question above.
  23
  24
  25 Source Code
  26 ===========
  27
  28 In what language is LLVM written?
  29 ---------------------------------
  30 All of the LLVM tools and libraries are written in C++ with extensive use of
  31 the STL.
  32
  33
  34 How portable is the LLVM source code?
  35 -------------------------------------
  36 The LLVM source code should be portable to most modern Unix-like operating
  37 systems. LLVM has also excellent support on Windows systems.
  38 Most of the code is written in standard C++ with operating system
  39 services abstracted to a support library.  The tools required to build and
  40 test LLVM have been ported to a plethora of platforms.
  41
  42
  43 What API do I use to store a value to one of the virtual registers in LLVM IR's SSA representation?
  44 ---------------------------------------------------------------------------------------------------
  45
  46 In short: you can't. It's actually kind of a silly question once you grok
  47 what's going on. Basically, in code like:
  48
  49 .. code-block:: llvm
  50
  51     %result = add i32 %foo, %bar
  52
  53 , ``%result`` is just a name given to the ``Value`` of the ``add``
  54 instruction. In other words, ``%result`` *is* the add instruction. The
  55 "assignment" doesn't explicitly "store" anything to any "virtual register";
  56 the "``=``" is more like the mathematical sense of equality.
  57
  58 Longer explanation: In order to generate a textual representation of the
  59 IR, some kind of name has to be given to each instruction so that other
  60 instructions can textually reference it. However, the isomorphic in-memory
  61 representation that you manipulate from C++ has no such restriction since
  62 instructions can simply keep pointers to any other ``Value``'s that they
  63 reference. In fact, the names of dummy numbered temporaries like ``%1`` are
  64 not explicitly represented in the in-memory representation at all (see
  65 ``Value::getName()``).
  66
  67
  68 Source Languages
  69 ================
  70
  71 What source languages are supported?
  72 ------------------------------------
  73
  74 LLVM currently has full support for C and C++ source languages through
  75 `Clang <http://clang.llvm.org/>`_. Many other language frontends have
  76 been written using LLVM, and an incomplete list is available at
  77 `projects with LLVM <http://llvm.org/ProjectsWithLLVM/>`_.
  78
  79
  80 I'd like to write a self-hosting LLVM compiler. How should I interface with the LLVM middle-end optimizers and back-end code generators?
  81 ----------------------------------------------------------------------------------------------------------------------------------------
  82 Your compiler front-end will communicate with LLVM by creating a module in the
  83 LLVM intermediate representation (IR) format. Assuming you want to write your
  84 language's compiler in the language itself (rather than C++), there are 3
  85 major ways to tackle generating LLVM IR from a front-end:
  86
  87 1. **Call into the LLVM libraries code using your language's FFI (foreign
  88    function interface).**
  89
  90   * *for:* best tracks changes to the LLVM IR, .ll syntax, and .bc format
  91
  92   * *for:* enables running LLVM optimization passes without a emit/parse
  93     overhead
  94
  95   * *for:* adapts well to a JIT context
  96
  97   * *against:* lots of ugly glue code to write
  98
  99 2. **Emit LLVM assembly from your compiler's native language.**
 100
 101   * *for:* very straightforward to get started
 102
 103   * *against:* the .ll parser is slower than the bitcode reader when
 104     interfacing to the middle end
 105
 106   * *against:* it may be harder to track changes to the IR
 107
 108 3. **Emit LLVM bitcode from your compiler's native language.**
 109
 110   * *for:* can use the more-efficient bitcode reader when interfacing to the
 111     middle end
 112
 113   * *against:* you'll have to re-engineer the LLVM IR object model and bitcode
 114     writer in your language
 115
 116   * *against:* it may be harder to track changes to the IR
 117
 118 If you go with the first option, the C bindings in include/llvm-c should help
 119 a lot, since most languages have strong support for interfacing with C. The
 120 most common hurdle with calling C from managed code is interfacing with the
 121 garbage collector. The C interface was designed to require very little memory
 122 management, and so is straightforward in this regard.
 123
 124 What support is there for a higher level source language constructs for building a compiler?
 125 --------------------------------------------------------------------------------------------
 126 Currently, there isn't much. LLVM supports an intermediate representation
 127 which is useful for code representation but will not support the high level
 128 (abstract syntax tree) representation needed by most compilers. There are no
 129 facilities for lexical nor semantic analysis.
 130
 131
 132 I don't understand the ``GetElementPtr`` instruction. Help!
 133 -----------------------------------------------------------
 134 See `The Often Misunderstood GEP Instruction <GetElementPtr.html>`_.
 135
 136
 137 Using the C and C++ Front Ends
 138 ==============================
 139
 140 Can I compile C or C++ code to platform-independent LLVM bitcode?
 141 -----------------------------------------------------------------
 142 No. C and C++ are inherently platform-dependent languages. The most obvious
 143 example of this is the preprocessor. A very common way that C code is made
 144 portable is by using the preprocessor to include platform-specific code. In
 145 practice, information about other platforms is lost after preprocessing, so
 146 the result is inherently dependent on the platform that the preprocessing was
 147 targeting.
 148
 149 Another example is ``sizeof``. It's common for ``sizeof(long)`` to vary
 150 between platforms. In most C front-ends, ``sizeof`` is expanded to a
 151 constant immediately, thus hard-wiring a platform-specific detail.
 152
 153 Also, since many platforms define their ABIs in terms of C, and since LLVM is
 154 lower-level than C, front-ends currently must emit platform-specific IR in
 155 order to have the result conform to the platform ABI.
 156
 157
 158 Questions about code generated by the demo page
 159 ===============================================
 160
 161 What is this ``llvm.global_ctors`` and ``_GLOBAL__I_a...`` stuff that happens when I ``#include <iostream>``?
 162 -------------------------------------------------------------------------------------------------------------
 163 If you ``#include`` the ``<iostream>`` header into a C++ translation unit,
 164 the file will probably use the ``std::cin``/``std::cout``/... global objects.
 165 However, C++ does not guarantee an order of initialization between static
 166 objects in different translation units, so if a static ctor/dtor in your .cpp
 167 file used ``std::cout``, for example, the object would not necessarily be
 168 automatically initialized before your use.
 169
 170 To make ``std::cout`` and friends work correctly in these scenarios, the STL
 171 that we use declares a static object that gets created in every translation
 172 unit that includes ``<iostream>``.  This object has a static constructor
 173 and destructor that initializes and destroys the global iostream objects
 174 before they could possibly be used in the file.  The code that you see in the
 175 ``.ll`` file corresponds to the constructor and destructor registration code.
 176
 177 If you would like to make it easier to *understand* the LLVM code generated
 178 by the compiler in the demo page, consider using ``printf()`` instead of
 179 ``iostream``\s to print values.
 180
 181
 182 Where did all of my code go??
 183 -----------------------------
 184 If you are using the LLVM demo page, you may often wonder what happened to
 185 all of the code that you typed in.  Remember that the demo script is running
 186 the code through the LLVM optimizers, so if your code doesn't actually do
 187 anything useful, it might all be deleted.
 188
 189 To prevent this, make sure that the code is actually needed.  For example, if
 190 you are computing some expression, return the value from the function instead
 191 of leaving it in a local variable.  If you really want to constrain the
 192 optimizer, you can read from and assign to ``volatile`` global variables.
 193
 194
 195 What is this "``undef``" thing that shows up in my code?
 196 --------------------------------------------------------
 197 ``undef`` is the LLVM way of representing a value that is not defined.  You
 198 can get these if you do not initialize a variable before you use it.  For
 199 example, the C function:
 200
 201 .. code-block:: c
 202
 203    int X() { int i; return i; }
 204
 205 Is compiled to "``ret i32 undef``" because "``i``" never has a value specified
 206 for it.
 207
 208
 209 Why does instcombine + simplifycfg turn a call to a function with a mismatched calling convention into "unreachable"? Why not make the verifier reject it?
 210 ----------------------------------------------------------------------------------------------------------------------------------------------------------
 211 This is a common problem run into by authors of front-ends that are using
 212 custom calling conventions: you need to make sure to set the right calling
 213 convention on both the function and on each call to the function.  For
 214 example, this code:
 215
 216 .. code-block:: llvm
 217
 218    define fastcc void @foo() {
 219        ret void
 220    }
 221    define void @bar() {
 222        call void @foo()
 223        ret void
 224    }
 225
 226 Is optimized to:
 227
 228 .. code-block:: llvm
 229
 230    define fastcc void @foo() {
 231        ret void
 232    }
 233    define void @bar() {
 234        unreachable
 235    }
 236
 237 ... with "``opt -instcombine -simplifycfg``".  This often bites people because
 238 "all their code disappears".  Setting the calling convention on the caller and
 239 callee is required for indirect calls to work, so people often ask why not
 240 make the verifier reject this sort of thing.
 241
 242 The answer is that this code has undefined behavior, but it is not illegal.
 243 If we made it illegal, then every transformation that could potentially create
 244 this would have to ensure that it doesn't, and there is valid code that can
 245 create this sort of construct (in dead code).  The sorts of things that can
 246 cause this to happen are fairly contrived, but we still need to accept them.
 247 Here's an example:
 248
 249 .. code-block:: llvm
 250
 251    define fastcc void @foo() {
 252        ret void
 253    }
 254    define internal void @bar(void()* %FP, i1 %cond) {
 255        br i1 %cond, label %T, label %F
 256    T:
 257        call void %FP()
 258        ret void
 259    F:
 260        call fastcc void %FP()
 261        ret void
 262    }
 263    define void @test() {
 264        %X = or i1 false, false
 265        call void @bar(void()* @foo, i1 %X)
 266        ret void
 267    }
 268
 269 In this example, "test" always passes ``@foo``/``false`` into ``bar``, which
 270 ensures that it is dynamically called with the right calling conv (thus, the
 271 code is perfectly well defined).  If you run this through the inliner, you
 272 get this (the explicit "or" is there so that the inliner doesn't dead code
 273 eliminate a bunch of stuff):
 274
 275 .. code-block:: llvm
 276
 277    define fastcc void @foo() {
 278        ret void
 279    }
 280    define void @test() {
 281        %X = or i1 false, false
 282        br i1 %X, label %T.i, label %F.i
 283    T.i:
 284        call void @foo()
 285        br label %bar.exit
 286    F.i:
 287        call fastcc void @foo()
 288        br label %bar.exit
 289    bar.exit:
 290        ret void
 291    }
 292
 293 Here you can see that the inlining pass made an undefined call to ``@foo``
 294 with the wrong calling convention.  We really don't want to make the inliner
 295 have to know about this sort of thing, so it needs to be valid code.  In this
 296 case, dead code elimination can trivially remove the undefined code.  However,
 297 if ``%X`` was an input argument to ``@test``, the inliner would produce this:
 298
 299 .. code-block:: llvm
 300
 301    define fastcc void @foo() {
 302        ret void
 303    }
 304
 305    define void @test(i1 %X) {
 306        br i1 %X, label %T.i, label %F.i
 307    T.i:
 308        call void @foo()
 309        br label %bar.exit
 310    F.i:
 311        call fastcc void @foo()
 312        br label %bar.exit
 313    bar.exit:
 314        ret void
 315    }
 316
 317 The interesting thing about this is that ``%X`` *must* be false for the
 318 code to be well-defined, but no amount of dead code elimination will be able
 319 to delete the broken call as unreachable.  However, since
 320 ``instcombine``/``simplifycfg`` turns the undefined call into unreachable, we
 321 end up with a branch on a condition that goes to unreachable: a branch to
 322 unreachable can never happen, so "``-inline -instcombine -simplifycfg``" is
 323 able to produce:
 324
 325 .. code-block:: llvm
 326
 327    define fastcc void @foo() {
 328       ret void
 329    }
 330    define void @test(i1 %X) {
 331    F.i:
 332       call fastcc void @foo()
 333       ret void
 334    }