From 58366820c460bebe6626c0818d83f5fb97a23888 Mon Sep 17 00:00:00 2001 From: Gordon Henriksen Date: Fri, 22 Feb 2008 20:58:29 +0000 Subject: [PATCH] Adding a note about IR generation to the LLVM FAQ. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47502 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/FAQ.html | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/docs/FAQ.html b/docs/FAQ.html index ea2f802d1dd..017a4d1a229 100644 --- a/docs/FAQ.html +++ b/docs/FAQ.html @@ -59,6 +59,9 @@
  • Source Languages
    1. What source languages are supported?
      2. +
    2. I'd like to write an LLVM compiler for my language. + How should I interface with the LLVM middle-end optimizers and back-end + code generators?
    3. What support is there for higher level source language constructs for building a compiler?
    4. I don't understand the GetElementPtr @@ -413,6 +416,57 @@ using llvm-gcc instead.

      The PyPy developers are working on integrating LLVM into the PyPy backend so that PyPy language can translate to LLVM.

      + +

      + I'd like to write an LLVM compiler for my language. How should I interface + with the LLVM middle-end optimizers and back-end code generators? +

      +
      +

      Your compiler front-end will communicate with LLVM by creating a module in + the LLVM intermediate representation (IR) format. There are 3 major ways to + tackle generating LLVM IR from a front-end:

      +
        +
      • + Call into the LLVM libraries code using your language's FFI + (foreign function interface). +
          +
        • for: best tracks changes to the LLVM IR, .ll syntax, + and .bc format
          • +
        • for: enables running LLVM optimization passes without a + emit/parse overhead
          • +
        • for: adapts well to a JIT context
          • +
        • against: lots of ugly glue code to write
          • +
        +
        • +
      • + Emit LLVM assembly from your compiler's native language. +
          +
        • for: very straightforward to get started
          • +
        • against: the .ll parser is slower than the bitcode reader + when interfacing to the middle end
          • +
        • against: you'll have to re-engineer the LLVM IR object + model and asm writer in your language
          • +
        • against: it may be harder to track changes to the IR
          • +
        +
        • +
      • + Emit LLVM bitcode from your compiler's native language. +
          +
        • for: can use the more-efficient bitcode reader when + interfacing to the middle end
          • +
        • against: you'll have to re-engineer the LLVM IR object + model and bitcode writer in your language
          • +
        • against: it may be harder to track changes to the IR
          • +
        +
        • +
      +

      If you go with the first option, the C bindings in include/llvm-c should + help a lot, since most languages have strong support for interfacing with + C. The most common hurdle with calling C from managed code is interfacing + with the garbage collector. The C interface was designed to require very + little memory management, and so is straightforward in this regard.

      +
      +

      What support is there for a higher level source language constructs for building a compiler?

      -- 2.34.1