X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FCodeGenerator.rst;h=cc099465b8eadf5add9dd99675873d2cb86ca208;hb=c90ddb186967525c41456565152d7cd898616bda;hp=20c99ced93b6f0eb7ff2ab73f300b88a3c6c7839;hpb=e0c345477174672897df399d9ba3ef4237933f59;p=oota-llvm.git diff --git a/docs/CodeGenerator.rst b/docs/CodeGenerator.rst index 20c99ced93b..cc099465b8e 100644 --- a/docs/CodeGenerator.rst +++ b/docs/CodeGenerator.rst @@ -70,7 +70,7 @@ different pieces of this will be useful to you. In any case, you should be familiar with the `target description`_ and `machine code representation`_ classes. If you want to add a backend for a new target, you will need to `implement the target description`_ classes for your new target and understand -the `LLVM code representation `_. If you are interested in +the :doc:`LLVM code representation `. If you are interested in implementing a new `code generation algorithm`_, it should only depend on the target-description and machine code representation classes, ensuring that it is portable. @@ -172,7 +172,7 @@ architecture. These target descriptions often have a large amount of common information (e.g., an ``add`` instruction is almost identical to a ``sub`` instruction). In order to allow the maximum amount of commonality to be factored out, the LLVM code generator uses the -:doc:`TableGen ` tool to describe big chunks of the +:doc:`TableGen/index` tool to describe big chunks of the target machine, which allows the use of domain-specific and target-specific abstractions to reduce the amount of repetition. @@ -277,7 +277,7 @@ an associated register class. When the register allocator runs, it replaces virtual registers with a physical register in the set. The target-specific implementations of these classes is auto-generated from a -`TableGen `_ description of the register file. +:doc:`TableGen/index` description of the register file. .. _TargetInstrInfo: @@ -434,12 +434,12 @@ For example, consider this simple LLVM example: .. code-block:: llvm define i32 @test(i32 %X, i32 %Y) { - %Z = udiv i32 %X, %Y + %Z = sdiv i32 %X, %Y ret i32 %Z } -The X86 instruction selector produces this machine code for the ``div`` and -``ret`` (use "``llc X.bc -march=x86 -print-machineinstrs``" to get this): +The X86 instruction selector might produce this machine code for the ``div`` and +``ret``: .. code-block:: llvm @@ -454,8 +454,8 @@ The X86 instruction selector produces this machine code for the ``div`` and %EAX = mov %reg1026 ;; 32-bit return value goes in EAX ret -By the end of code generation, the register allocator has coalesced the -registers and deleted the resultant identity moves producing the following +By the end of code generation, the register allocator would coalesce the +registers and delete the resultant identity moves producing the following code: .. code-block:: llvm @@ -636,6 +636,18 @@ file (MCObjectStreamer). MCAsmStreamer is a straight-forward implementation that prints out a directive for each method (e.g. ``EmitValue -> .byte``), but MCObjectStreamer implements a full assembler. +For target specific directives, the MCStreamer has a MCTargetStreamer instance. +Each target that needs it defines a class that inherits from it and is a lot +like MCStreamer itself: It has one method per directive and two classes that +inherit from it, a target object streamer and a target asm streamer. The target +asm streamer just prints it (``emitFnStart -> .fnstrart``), and the object +streamer implement the assembler logic for it. + +To make llvm use these classes, the target initialization must call +TargetRegistry::RegisterAsmStreamer and TargetRegistry::RegisterMCObjectStreamer +passing callbacks that allocate the corresponding target streamer and pass it +to createAsmStreamer or to the appropriate object streamer constructor. + The ``MCContext`` class ----------------------- @@ -1614,7 +1626,7 @@ Implementing a Native Assembler =============================== Though you're probably reading this because you want to write or maintain a -compiler backend, LLVM also fully supports building a native assemblers too. +compiler backend, LLVM also fully supports building a native assembler. We've tried hard to automate the generation of the assembler from the .td files (in particular the instruction syntax and encodings), which means that a large part of the manual and repetitive data entry can be factored and shared with the @@ -1788,12 +1800,12 @@ Here is the table: :raw-html:`Feature` :raw-html:`ARM` :raw-html:`Hexagon` -:raw-html:`MBlaze` :raw-html:`MSP430` :raw-html:`Mips` :raw-html:`NVPTX` :raw-html:`PowerPC` :raw-html:`Sparc` +:raw-html:`SystemZ` :raw-html:`X86` :raw-html:`XCore` :raw-html:`` @@ -1802,12 +1814,12 @@ Here is the table: :raw-html:`is generally reliable` :raw-html:` ` :raw-html:` ` -:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` +:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:`` @@ -1816,12 +1828,12 @@ Here is the table: :raw-html:`assembly parser` :raw-html:` ` :raw-html:` ` -:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` +:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:`` @@ -1830,11 +1842,11 @@ Here is the table: :raw-html:`disassembler` :raw-html:` ` :raw-html:` ` -:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` +:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` @@ -1844,12 +1856,12 @@ Here is the table: :raw-html:`inline asm` :raw-html:` ` :raw-html:` ` -:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` +:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:`` @@ -1858,12 +1870,12 @@ Here is the table: :raw-html:`jit` :raw-html:`* ` :raw-html:` ` -:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` +:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:`` @@ -1872,12 +1884,12 @@ Here is the table: :raw-html:`.o file writing` :raw-html:` ` :raw-html:` ` -:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` +:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:`` @@ -1886,12 +1898,12 @@ Here is the table: :raw-html:`tail calls` :raw-html:` ` :raw-html:` ` -:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` +:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:`` @@ -1900,12 +1912,12 @@ Here is the table: :raw-html:`segmented stacks` :raw-html:` ` :raw-html:` ` -:raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` :raw-html:` ` +:raw-html:` ` :raw-html:`* ` :raw-html:` ` :raw-html:`` @@ -1981,7 +1993,7 @@ Tail Calls This box indicates whether the target supports guaranteed tail calls. These are calls marked "`tail `_" and use the fastcc calling -convention. Please see the `tail call section more more details`_. +convention. Please see the `tail call section`_ for more details. .. _feat_segstacks: @@ -1999,7 +2011,7 @@ Basic support exists on the X86 backend. Currently vararg doesn't work and the object files are not marked the way the gold linker expects, but simple Go programs can be built by dragonegg. -.. _tail call section more more details: +.. _tail call section: Tail call optimization ----------------------