diff --git a/llvm/docs/CodeGenerator.rst b/llvm/docs/CodeGenerator.rst index eda8bf6489bda..7486054b55c9f 100644 --- a/llvm/docs/CodeGenerator.rst +++ b/llvm/docs/CodeGenerator.rst @@ -90,8 +90,8 @@ This design has two important implications. The first is that LLVM can support completely non-traditional code generation targets. For example, the C backend does not require register allocation, instruction selection, or any of the other standard components provided by the system. As such, it only implements these -two interfaces, and does its own thing. Note that C backend was removed from the -trunk since LLVM 3.1 release. Another example of a code generator like this is a +two interfaces, and does its own thing. Note that the C backend was removed from the +trunk in the LLVM 3.1 release. Another example of a code generator like this is a (purely hypothetical) backend that converts LLVM to the GCC RTL form and uses GCC to emit machine code for a target. @@ -565,7 +565,7 @@ Conceptually a MI bundle is a MI with a number of other MIs nested within: MI bundle support does not change the physical representations of MachineBasicBlock and MachineInstr. All the MIs (including top level and nested ones) are stored as sequential list of MIs. The "bundled" MIs are marked with -the 'InsideBundle' flag. A top level MI with the special BUNDLE opcode is used +the 'InsideBundle' flag. A top-level MI with the special BUNDLE opcode is used to represent the start of a bundle. It's legal to mix BUNDLE MIs with individual MIs that are not inside bundles nor represent bundles. @@ -575,7 +575,7 @@ The MachineBasicBlock iterator has been modified to skip over bundled MIs to enforce the bundle-as-a-single-unit concept. An alternative iterator instr_iterator has been added to MachineBasicBlock to allow passes to iterate over all of the MIs in a MachineBasicBlock, including those which are nested -inside bundles. The top level BUNDLE instruction must have the correct set of +inside bundles. The top-level BUNDLE instruction must have the correct set of register MachineOperand's that represent the cumulative inputs and outputs of the bundled MIs. @@ -602,7 +602,7 @@ level, devoid of "high level" information like "constant pools", "jump tables", "global variables" or anything like that. At this level, LLVM handles things like label names, machine instructions, and sections in the object file. The code in this layer is used for a number of important purposes: the tail end of -the code generator uses it to write a .s or .o file, and it is also used by the +the code generator uses it to write a ``.s`` or ``.o`` file, and it is also used by the llvm-mc tool to implement standalone machine code assemblers and disassemblers. This section describes some of the important classes. There are also a number @@ -615,8 +615,8 @@ The ``MCStreamer`` API ---------------------- MCStreamer is best thought of as an assembler API. It is an abstract API which -is *implemented* in different ways (e.g. to output a .s file, output an ELF .o -file, etc) but whose API correspond directly to what you see in a .s file. +is *implemented* in different ways (e.g. to output a ``.s`` file, output an ELF ``.o`` +file, etc) but whose API corresponds directly to what you see in a ``.s`` file. MCStreamer has one method per directive, such as EmitLabel, EmitSymbolAttribute, switchSection, emitValue (for .byte, .word), etc, which directly correspond to assembly level directives. It also has an EmitInstruction method, which is used @@ -629,7 +629,7 @@ higher level LLVM IR and Machine* constructs down to the MC layer, emitting directives through MCStreamer. On the implementation side of MCStreamer, there are two major implementations: -one for writing out a .s file (MCAsmStreamer), and one for writing out a .o +one for writing out a ``.s`` file (MCAsmStreamer), and one for writing out a ``.o`` file (MCObjectStreamer). MCAsmStreamer is a straightforward implementation that prints out a directive for each method (e.g. ``EmitValue -> .byte``), but MCObjectStreamer implements a full assembler. @@ -639,7 +639,7 @@ 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 -> .fnstart``), and the object -streamer implement the assembler logic for it. +streamer implements the assembler logic for it. To make llvm use these classes, the target initialization must call TargetRegistry::RegisterAsmStreamer and TargetRegistry::RegisterMCObjectStreamer @@ -667,7 +667,7 @@ MCSymbols are created by MCContext and uniqued there. This means that MCSymbols can be compared for pointer equivalence to find out if they are the same symbol. Note that pointer inequality does not guarantee the labels will end up at different addresses though. It's perfectly legal to output something like this -to the .s file: +to the ``.s`` file: :: @@ -685,7 +685,7 @@ subclassed by object file specific implementations (e.g. ``MCSectionMachO``, ``MCSectionCOFF``, ``MCSectionELF``) and these are created and uniqued by MCContext. The MCStreamer has a notion of the current section, which can be changed with the SwitchToSection method (which corresponds to a ".section" -directive in a .s file). +directive in a ``.s`` file). .. _MCInst: @@ -887,7 +887,7 @@ bundled into a single scheduling-unit node, and with immediate operands and other nodes that aren't relevant for scheduling omitted. The option ``-filter-view-dags`` allows to select the name of the basic block -that you are interested to visualize and filters all the previous +that you are interested in visualizing and filters all the previous ``view-*-dags`` options. .. _Build initial DAG: @@ -944,7 +944,7 @@ The Legalize phase is in charge of converting a DAG to only use the operations that are natively supported by the target. Targets often have weird constraints, such as not supporting every operation on -every supported datatype (e.g. X86 does not support byte conditional moves and +every supported data type (e.g. X86 does not support byte conditional moves and PowerPC does not support sign-extending loads from a 16-bit memory location). Legalize takes care of this by open-coding another sequence of operations to emulate the operation ("expansion"), by promoting one type to a larger type that @@ -1077,7 +1077,7 @@ for your target. It has the following strengths: if your patterns make sense or not. * It can handle arbitrary constraints on operands for the pattern match. In - particular, it is straight-forward to say things like "match any immediate + particular, it is straightforward to say things like "match any immediate that is a 13-bit sign-extended value". For examples, see the ``immSExt16`` and related ``tblgen`` classes in the PowerPC backend. @@ -1615,7 +1615,7 @@ Since the MC layer works at the level of abstraction of object files, it doesn't have a notion of functions, global variables etc. Instead, it thinks about labels, directives, and instructions. A key class used at this time is the MCStreamer class. This is an abstract API that is implemented in different ways -(e.g. to output a .s file, output an ELF .o file, etc) that is effectively an +(e.g. to output a ``.s`` file, output an ELF ``.o`` file, etc) that is effectively an "assembler API". MCStreamer has one method per directive, such as EmitLabel, EmitSymbolAttribute, switchSection, etc, which directly correspond to assembly level directives. @@ -1648,7 +1648,7 @@ three important things that you have to implement for your target: Finally, at your choosing, you can also implement a subclass of MCCodeEmitter which lowers MCInst's into machine code bytes and relocations. This is -important if you want to support direct .o file emission, or would like to +important if you want to support direct ``.o`` file emission, or would like to implement an assembler for your target. Emitting function stack size information @@ -1678,7 +1678,7 @@ Instructions in a VLIW target can typically be mapped to multiple functional units. During the process of packetizing, the compiler must be able to reason about whether an instruction can be added to a packet. This decision can be complex since the compiler has to examine all possible mappings of instructions -to functional units. Therefore to alleviate compilation-time complexity, the +to functional units. Therefore, to alleviate compilation-time complexity, the VLIW packetizer parses the instruction classes of a target and generates tables at compiler build time. These tables can then be queried by the provided machine-independent API to determine if an instruction can be accommodated in a @@ -1729,7 +1729,7 @@ Instruction Alias Processing ---------------------------- Once the instruction is parsed, it enters the MatchInstructionImpl function. -The MatchInstructionImpl function performs alias processing and then does actual +The MatchInstructionImpl function performs alias processing and then performs actual matching. Alias processing is the phase that canonicalizes different lexical forms of the @@ -1934,7 +1934,7 @@ following constraints are met: * Caller and callee have matching return type or the callee result is not used. -* If any of the callee arguments are being passed in stack, they must be +* If any of the callee arguments are being passed on the stack, they must be available in caller's own incoming argument stack and the frame offsets must be the same. @@ -2074,7 +2074,7 @@ character per operand with an optional special size. For example: The PowerPC backend ------------------- -The PowerPC code generator lives in the lib/Target/PowerPC directory. The code +The PowerPC code generator lives in the ``lib/Target/PowerPC`` directory. The code generation is retargetable to several variations or *subtargets* of the PowerPC ISA; including ppc32, ppc64 and altivec. @@ -2140,7 +2140,7 @@ previous frame pointer (r31.) The entries in the linkage area are the size of a GPR, thus the linkage area is 24 bytes long in 32-bit mode and 48 bytes in 64-bit mode. -32 bit linkage area: +32-bit linkage area: :raw-html:`` :raw-html:`` @@ -2169,7 +2169,7 @@ GPR, thus the linkage area is 24 bytes long in 32-bit mode and 48 bytes in :raw-html:`` :raw-html:`
` -64 bit linkage area: +64-bit linkage area: :raw-html:`` :raw-html:``