This document describes the LLVM bitstream file format and the encoding of the LLVM IR into it.
@@ -61,7 +61,7 @@ the LLVM IR into it.What is commonly known as the LLVM bitcode file format (also, sometimes @@ -91,7 +91,7 @@ wrapper format, then describes the record structure used by LLVM IR files.
The bitstream format is literally a stream of bits, with a very simple @@ -114,14 +114,12 @@ href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer tool can be used to dump and inspect arbitrary bitstreams, which is very useful for understanding the encoding.
-The first two bytes of a bitcode file are 'BC' (0x42, 0x43). The second two bytes are an application-specific magic number. Generic @@ -135,7 +133,7 @@ bitcode, while application-specific programs will want to look at all four.
Primitives -A bitstream literally consists of a stream of bits, which are read in order @@ -146,14 +144,12 @@ Width Integers or as Variable Width Integers.
-Fixed-width integer values have their low bits emitted directly to the file. For example, a 3-bit integer value encodes 1 as 001. Fixed width integers @@ -168,7 +164,7 @@ Integers. Variable Width Integers -
Variable-width integer (VBR) values encode values of arbitrary size, optimizing for the case where the values are small. Given a 4-bit VBR field, @@ -188,7 +184,7 @@ value of 24 (011 << 3) with no continuation. The sum (3+24) yields the value
6-bit characters encode common characters into a fixed 6-bit field. They represent the following characters with the following 6-bit values:
@@ -212,7 +208,7 @@ characters not in the set.Occasionally, it is useful to emit zero bits until the bitstream is a multiple of 32 bits. This ensures that the bit position in the stream can be @@ -220,13 +216,14 @@ represented as a multiple of 32-bit words.
A bitstream is a sequential series of Blocks and @@ -262,7 +259,7 @@ an abbreviated record encoding.
Blocks -Blocks in a bitstream denote nested regions of the stream, and are identified by @@ -303,12 +300,10 @@ its own set of abbreviations, and its own abbrev id width. When a sub-block is popped, the saved values are restored.
-[ENTER_SUBBLOCK, blockidvbr8, newabbrevlenvbr4, <align32bits>, blocklen32]
@@ -329,7 +324,7 @@ reader to skip over the entire block in one jump.[END_BLOCK, <align32bits>]
@@ -341,14 +336,14 @@ an even multiple of 32-bits.Data records consist of a record code and a number of (up to) 64-bit integer values. The interpretation of the code and values is @@ -360,12 +355,10 @@ which encodes the target triple of a module. The code is ASCII codes for the characters in the string.
-[UNABBREV_RECORD, codevbr6, numopsvbr6, op0vbr6, op1vbr6, ...]
@@ -391,7 +384,7 @@ bits. This is not an efficient encoding, but it is fully general.[<abbrevid>, fields...]
@@ -412,12 +405,14 @@ operand value).Abbreviations are an important form of compression for bitstreams. The idea is to specify a dense encoding for a class of records once, then use that encoding @@ -435,12 +430,11 @@ As a concrete example, LLVM IR files usually emit an abbreviation for binary operators. If a specific LLVM module contained no or few binary operators, the abbreviation does not need to be emitted.
-[DEFINE_ABBREV, numabbrevopsvbr5, abbrevop0, abbrevop1, ...]
@@ -555,12 +549,14 @@ used for any other string value.In addition to the basic block structure and record encodings, the bitstream @@ -569,12 +565,10 @@ stream is to be decoded or other metadata. In the future, new standard blocks may be added. Block IDs 0-7 are reserved for standard blocks.
-The BLOCKINFO block allows the description of metadata for other @@ -623,11 +617,15 @@ from the corresponding blocks. It is not safe to skip them.
Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper @@ -658,7 +656,7 @@ value that can be used to encode the CPU of the target.
LLVM IR is encoded into a bitstream by defining blocks and records. It uses @@ -669,17 +667,17 @@ that the writer uses, as these are fully self-described in the file, and the reader is not allowed to build in any knowledge of this.
-The magic number for LLVM IR files is: @@ -701,7 +699,7 @@ When combined with the bitcode magic number and viewed as bytes, this is
Variable Width Integer encoding is an efficient way to @@ -734,7 +732,7 @@ within CONSTANTS_BLOCK blocks.
LLVM IR is defined with the following blocks: @@ -762,12 +760,14 @@ LLVM IR is defined with the following blocks:
The MODULE_BLOCK block (id 8) is the top-level block for LLVM bitcode files, and each bitcode file must contain exactly one. In @@ -787,12 +787,10 @@ following sub-blocks:
[VERSION, version#]
@@ -804,7 +802,7 @@ time.[TRIPLE, ...string...]
The TRIPLE record (code 2) contains a variable number of @@ -815,7 +813,7 @@ specification string.
[DATALAYOUT, ...string...]
The DATALAYOUT record (code 3) contains a variable number of @@ -826,7 +824,7 @@ specification string.
[ASM, ...string...]
The ASM record (code 4) contains a variable number of @@ -837,7 +835,7 @@ individual assembly blocks separated by newline (ASCII 10) characters.
[SECTIONNAME, ...string...]
The SECTIONNAME record (code 5) contains a variable number @@ -852,7 +850,7 @@ referenced by the 1-based index in the section fields of
[DEPLIB, ...string...]
The DEPLIB record (code 6) contains a variable number of @@ -865,7 +863,7 @@ library name referenced.
[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal]
The GLOBALVAR record (code 7) marks the declaration or @@ -929,7 +927,7 @@ has unnamed_addr
[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc]
@@ -985,7 +983,7 @@ has unnamed_addr[ALIAS, alias type, aliasee val#, linkage, visibility]
@@ -1009,7 +1007,7 @@ for this alias[PURGEVALS, numvals]
The PURGEVALS record (code 10) resets the module-level @@ -1022,7 +1020,7 @@ new value indices will start from the given numvals value.
[GCNAME, ...string...]
The GCNAME record (code 11) contains a variable number of @@ -1033,12 +1031,14 @@ the module. These records can be referenced by 1-based index in the gc fields of FUNCTION records.
The PARAMATTR_BLOCK block (id 9) contains a table of entries describing the attributes of function parameters. These @@ -1052,13 +1052,10 @@ href="#FUNC_CODE_INST_CALL">INST_CALL records.
that each is unique (i.e., no two indicies represent equivalent attribute lists). -[ENTRY, paramidx0, attr0, paramidx1, attr1...]
@@ -1099,12 +1096,14 @@ the logarithm base 2 of the requested alignment, plus 1The TYPE_BLOCK block (id 10) contains records which constitute a table of type operator entries used to represent types @@ -1119,12 +1118,10 @@ type operator records. each entry is unique (i.e., no two indicies represent structurally equivalent types).
-[NUMENTRY, numentries]
@@ -1138,7 +1135,7 @@ in the block.[VOID]
@@ -1150,7 +1147,7 @@ type table.[FLOAT]
@@ -1162,7 +1159,7 @@ floating point) type to the type table.[DOUBLE]
@@ -1174,7 +1171,7 @@ floating point) type to the type table.[LABEL]
@@ -1186,7 +1183,7 @@ the type table.[OPAQUE]
@@ -1199,7 +1196,7 @@ unified.[INTEGER, width]
@@ -1212,7 +1209,7 @@ integer type.[POINTER, pointee type, address space]
@@ -1232,7 +1229,7 @@ default address space is zero.[FUNCTION, vararg, ignored, retty, ...paramty... ]
@@ -1256,7 +1253,7 @@ parameter types of the function[STRUCT, ispacked, ...eltty...]
@@ -1274,7 +1271,7 @@ types of the structure[ARRAY, numelts, eltty]
@@ -1291,7 +1288,7 @@ table. The operand fields are[VECTOR, numelts, eltty]
@@ -1308,7 +1305,7 @@ table. The operand fields are[X86_FP80]
@@ -1320,7 +1317,7 @@ floating point) type to the type table.[FP128]
@@ -1332,7 +1329,7 @@ floating point) type to the type table.[PPC_FP128]
@@ -1344,7 +1341,7 @@ floating point) type to the type table.[METADATA]
@@ -1353,12 +1350,14 @@ type to the type table.The CONSTANTS_BLOCK block (id 11) ...
@@ -1371,7 +1370,7 @@ type to the type table. FUNCTION_BLOCK Contents -The FUNCTION_BLOCK block (id 12) ...
@@ -1394,19 +1393,17 @@ type to the type table. TYPE_SYMTAB_BLOCK Contents -The TYPE_SYMTAB_BLOCK block (id 13) contains entries which map between module-level named types and their corresponding type indices.
-[ENTRY, typeid, ...string...]
@@ -1417,13 +1414,14 @@ name. Each entry corresponds to a single named type.The VALUE_SYMTAB_BLOCK block (id 14) ...
@@ -1436,7 +1434,7 @@ name. Each entry corresponds to a single named type. METADATA_BLOCK Contents -The METADATA_BLOCK block (id 15) ...
@@ -1449,13 +1447,14 @@ name. Each entry corresponds to a single named type. METADATA_ATTACHMENT Contents -The METADATA_ATTACHMENT block (id 16) ...
bugpoint narrows down the source of problems in LLVM tools and passes. It can be used to debug three types of failures: optimizer crashes, @@ -55,7 +55,7 @@ href="HowToSubmitABug.html">How To Submit a Bug Report document.
-bugpoint is designed to be a useful tool without requiring any hooks into the LLVM infrastructure at all. It works with any and all LLVM @@ -68,14 +68,12 @@ is still worth it. Note that bugpoint is generally very quick unless debugging a miscompilation where each test of the program (which requires executing it) takes a long time.
-bugpoint reads each .bc or .ll file specified on the command line and links them together into a single module, called the test @@ -108,7 +106,7 @@ Otherwise, there is no problem bugpoint can debug.
Crash debugger -If an optimizer or code generator crashes, bugpoint will try as hard as it can to reduce the list of passes (for optimizer crashes) and the size of @@ -133,7 +131,7 @@ reproduce the failure with opt or llc.
Code generator debugger -The code generator debugger attempts to narrow down the amount of code that is being miscompiled by the selected code generator. To do this, it takes the @@ -154,7 +152,7 @@ good code.
Miscompilation debugger -The miscompilation debugger works similarly to the code generator debugger. It works by splitting the test program into two pieces, running the @@ -166,13 +164,15 @@ assumes that the selected code generator is working properly.
diff --git a/docs/CMake.html b/docs/CMake.html index 8ea4377dd51..ba232080cd2 100644 --- a/docs/CMake.html +++ b/docs/CMake.html @@ -41,7 +41,7 @@ -
CMake is a cross-platform build-generator tool. CMake does not build the project, it generates @@ -64,7 +64,7 @@ -
We use here the command-line, non-interactive CMake interface
@@ -117,7 +117,7 @@ -This section explains basic aspects of CMake, mostly for explaining those options which you may need on your day-to-day @@ -165,7 +165,7 @@ -
Variables customize how the build will be generated. Options are boolean variables, with possible values ON/OFF. Options and @@ -194,14 +194,12 @@
cmake -DVARIABLE:TYPE=value path/to/llvm/source
Here are listed some of the CMake variables that are used often, along with a brief explanation and LLVM-specific notes. For full @@ -244,7 +242,7 @@ LLVM-specific variables -
Testing is performed when the check target is built. For instance, if you are using makefiles, execute this command while on @@ -383,7 +383,7 @@ -
See this wiki page for generic instructions on how to cross-compile @@ -404,7 +404,7 @@ -
The most difficult part of adding LLVM to the build of a project is to determine the set of LLVM libraries corresponding to the set @@ -459,14 +459,12 @@
It is possible to develop LLVM passes against installed LLVM. An example of project layout provided below:
@@ -518,23 +516,23 @@Notes for specific compilers and/or platforms.
-The LLVM target-independent code generator is a framework that provides a suite of reusable components for translating the LLVM internal representation @@ -188,14 +188,12 @@ depend on the target-description and machine code representation classes, ensuring that it is portable.
-The two pieces of the LLVM code generator are the high-level interface to the code generator and the set of reusable components that can be used to build @@ -227,7 +225,7 @@ The high-level design of the code generator -
The LLVM target-independent code generator is designed to support efficient and quality code generation for standard register-based microprocessors. @@ -301,7 +299,7 @@ Using TableGen for target description -
The target description classes require a detailed description of the target architecture. These target descriptions often have a large amount of common @@ -324,13 +322,15 @@
The LLVM target description classes (located in the include/llvm/Target directory) provide an abstract description of @@ -346,14 +346,12 @@ TargetMachine class provides accessors that should be implemented by the target.
-The TargetMachine class provides virtual methods that are used to access the target-specific implementations of the various target description @@ -373,7 +371,7 @@ The TargetData class -
The TargetData class is the only required target description class, and it is the only class that is not extensible (you cannot derived a new @@ -389,7 +387,7 @@ The TargetLowering class -
The TargetLowering class is used by SelectionDAG based instruction selectors primarily to describe how LLVM code should be lowered to @@ -415,7 +413,7 @@ The TargetRegisterInfo class -
The TargetRegisterInfo class is used to describe the register file of the target and any interactions between the registers.
@@ -449,7 +447,7 @@ The TargetInstrInfo class -The TargetInstrInfo class is used to describe the machine instructions supported by the target. It is essentially an array of @@ -467,7 +465,7 @@ The TargetFrameInfo class -
The TargetFrameInfo class is used to provide information about the stack frame layout of the target. It holds the direction of stack growth, the @@ -483,7 +481,7 @@ The TargetSubtarget class -
The TargetSubtarget class is used to provide information about the specific chip set being targeted. A sub-target informs code generation of @@ -499,7 +497,7 @@ The TargetJITInfo class -
The TargetJITInfo class exposes an abstract interface used by the Just-In-Time code generator to perform target-specific activities, such as @@ -509,13 +507,15 @@
At the high-level, LLVM code is translated to a machine specific representation formed out of @@ -528,14 +528,12 @@ SSA representation for machine code, as well as a register allocated, non-SSA form.
-Target machine instructions are represented as instances of the MachineInstr class. This class is an extremely abstract way of @@ -576,14 +574,12 @@
Also if the first operand is a def, it is easier to create instructions whose only def is the first operand.
-Machine instructions are created by using the BuildMI functions, located in the include/llvm/CodeGen/MachineInstrBuilder.h file. The @@ -634,7 +630,7 @@ MI.addReg(Reg, RegState::Define); Fixed (preassigned) registers -
One important issue that the code generator needs to be aware of is the presence of fixed registers. In particular, there are often places in the @@ -706,7 +702,7 @@ ret Machine code in SSA form -
MachineInstr's are initially selected in SSA-form, and are maintained in SSA-form until register allocation happens. For the most part, @@ -719,12 +715,14 @@ ret
The MachineBasicBlock class contains a list of machine instructions (MachineInstr instances). It roughly @@ -741,7 +739,7 @@ ret The MachineFunction class -
The MachineFunction class contains a list of machine basic blocks (MachineBasicBlock instances). It @@ -754,6 +752,7 @@ ret
The MC Layer is used to represent and process code at the raw machine code @@ -779,15 +778,12 @@ of important subsystems that interact at this layer, they are described later in this manual.
-MCStreamer is best thought of as an assembler API. It is an abstract API which @@ -821,7 +817,7 @@ MCObjectStreamer implements a full assembler. The MCContext class -
The MCContext class is the owner of a variety of uniqued data structures at the @@ -836,7 +832,7 @@ interact with to create symbols and sections. This class can not be subclassed. The MCSymbol class -
The MCSymbol class represents a symbol (aka label) in the assembly file. There @@ -868,7 +864,7 @@ like this to the .s file:
The MCSection class represents an object-file specific section. It is subclassed @@ -886,7 +882,7 @@ directive in a .s file). The MCInst class -
The MCInst class is a target-independent representation of an instruction. It @@ -904,6 +900,7 @@ printer, and the type generated by the assembly parser and disassembler.
This section documents the phases described in the high-level design of the code generator. It explains how they work and some of the rationale behind their design.
-Instruction Selection is the process of translating LLVM code presented to the code generator into target-specific machine instructions. There are @@ -936,14 +931,12 @@ printer, and the type generated by the assembly parser and disassembler. selector to be generated from these .td files, though currently there are still things that require custom C++ code.
-The SelectionDAG provides an abstraction for code representation in a way that is amenable to instruction selection using automatic techniques @@ -1005,7 +998,7 @@ printer, and the type generated by the assembly parser and disassembler. SelectionDAG Instruction Selection Process -
SelectionDAG-based instruction selection consists of the following steps:
@@ -1086,7 +1079,7 @@ printer, and the type generated by the assembly parser and disassembler. Initial SelectionDAG Construction -The initial SelectionDAG is naïvely peephole expanded from the LLVM input by the SelectionDAGLowering class in the @@ -1106,7 +1099,7 @@ printer, and the type generated by the assembly parser and disassembler. SelectionDAG LegalizeTypes Phase -
The Legalize phase is in charge of converting a DAG to only use the types that are natively supported by the target.
@@ -1139,7 +1132,7 @@ printer, and the type generated by the assembly parser and disassembler. SelectionDAG Legalize Phase -The Legalize phase is in charge of converting a DAG to only use the operations that are natively supported by the target.
@@ -1173,7 +1166,7 @@ printer, and the type generated by the assembly parser and disassembler. -The SelectionDAG optimization phase is run multiple times for code generation, immediately after the DAG is built and once after each @@ -1207,7 +1200,7 @@ printer, and the type generated by the assembly parser and disassembler. SelectionDAG Select Phase -
The Select phase is the bulk of the target-specific code for instruction selection. This phase takes a legal SelectionDAG as input, pattern matches @@ -1368,7 +1361,7 @@ def : Pat<(i32 imm:$imm), SelectionDAG Scheduling and Formation Phase -
The scheduling phase takes the DAG of target instructions from the selection phase and assigns an order. The scheduler can pick an order depending on @@ -1389,7 +1382,7 @@ def : Pat<(i32 imm:$imm), Future directions for the SelectionDAG -
To Be Written
To Be Written
Live Intervals are the ranges (intervals) where a variable is live. They are used by some register allocator passes to @@ -1418,14 +1413,12 @@ def : Pat<(i32 imm:$imm), register are live at the same point in the program (i.e., they conflict). When this situation occurs, one virtual register must be spilled.
-The first step in determining the live intervals of variables is to calculate the set of registers that are immediately dead after the instruction (i.e., @@ -1471,7 +1464,7 @@ def : Pat<(i32 imm:$imm), Live Intervals Analysis -
We now have the information available to perform the live intervals analysis and build the live intervals themselves. We start off by numbering the basic @@ -1486,12 +1479,14 @@ def : Pat<(i32 imm:$imm),
The Register Allocation problem consists in mapping a program Pv, that can use an unbounded number of virtual registers, @@ -1501,15 +1496,13 @@ def : Pat<(i32 imm:$imm), accommodate all the virtual registers, some of them will have to be mapped into memory. These virtuals are called spilled virtuals.
-In LLVM, physical registers are denoted by integer numbers that normally range from 1 to 1023. To see how this numbering is defined for a particular @@ -1622,7 +1615,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, Mapping virtual registers to physical registers -
There are two ways to map virtual registers to physical registers (or to memory slots). The first way, that we will call direct mapping, is @@ -1672,7 +1665,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, Handling two address instructions -
With very rare exceptions (e.g., function calls), the LLVM machine code instructions are three address instructions. That is, each instruction is @@ -1708,7 +1701,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, The SSA deconstruction phase -
An important transformation that happens during register allocation is called the SSA Deconstruction Phase. The SSA form simplifies many analyses @@ -1732,7 +1725,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, Instruction folding -
Instruction folding is an optimization performed during register allocation that removes unnecessary copy instructions. For instance, a @@ -1769,7 +1762,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, Built in register allocators -
The LLVM infrastructure provides the application developer with three different register allocators:
@@ -1806,23 +1799,25 @@ $ llc -regalloc=pbqp file.bc -o pbqp.s;To Be Written
To Be Written
To Be Written
To Be Written
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. @@ -1897,12 +1893,10 @@ We've tried hard to automate the generation of the assembler from the .td files part of the manual and repetitive data entry can be factored and shared with the compiler.
-To Be Written
To Be Written
Once the instruction is parsed, it enters the MatchInstructionImpl function. The MatchInstructionImpl function performs alias processing and then does actual matching.
@@ -1923,12 +1917,10 @@ complex/powerful). Generally you want to use the first alias mechanism that meets the needs of your instruction, because it will allow a more concise description. -The first phase of alias processing is simple instruction mnemonic remapping for classes of instructions which are allowed with two different @@ -1968,7 +1960,7 @@ on the current instruction set.
The most general phase of alias processing occurs while matching is happening: it provides new forms for the matcher to match along with a specific @@ -2029,15 +2021,14 @@ subtarget specific.
To Be Written
To Be Written
This section of the document explains features or design decisions that are specific to the code generator for a particular target. First we start with a table that summarizes what features are supported by each target.
-Note that this table does not include the C backend or Cpp backends, since they do not use the target independent code generator infrastructure. It also @@ -2229,12 +2218,10 @@ is the key:
-This box indicates whether the target is considered to be production quality. This indicates that the target has been used as a static compiler to compile large amounts of code by a variety of different people and is in @@ -2244,7 +2231,7 @@ continuous use.
This box indicates whether the target supports parsing target specific .s files by implementing the MCAsmParser interface. This is required for llvm-mc to be able to act as a native assembler and is required for inline assembly @@ -2256,7 +2243,7 @@ support in the native .o file writer.
This box indicates whether the target supports the MCDisassembler API for disassembling machine opcode bytes into MCInst's.
@@ -2265,7 +2252,7 @@ disassembling machine opcode bytes into MCInst's.This box indicates whether the target supports most popular inline assembly constraints and modifiers.
@@ -2277,7 +2264,7 @@ constraints relating to the X86 floating point stack.This box indicates whether the target supports the JIT compiler through the ExecutionEngine interface.
@@ -2289,7 +2276,7 @@ in ARM codegen mode, but lacks NEON and full Thumb support.This box indicates whether the target supports writing .o files (e.g. MachO, ELF, and/or COFF) files directly from the target. Note that the target also @@ -2305,7 +2292,7 @@ file to a .o file (as is the case for many C compilers).
This box indicates whether the target supports guaranteed tail calls. These are calls marked "tail" and use the fastcc @@ -2314,15 +2301,14 @@ more more details.
Tail call optimization, callee reusing the stack of the caller, is currently supported on x86/x86-64 and PowerPC. It is performed if:
@@ -2388,7 +2374,7 @@ define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { Sibling call optimization -Sibling call optimization is a restricted form of tail call optimization. Unlike tail call optimization described in the previous section, it can be @@ -2432,20 +2418,18 @@ entry: The X86 backend -
The X86 code generator lives in the lib/Target/X86 directory. This code generator is capable of targeting a variety of x86-32 and x86-64 processors, and includes support for ISA extensions such as MMX and SSE.
-The following are the known target triples that are supported by the X86 backend. This is not an exhaustive list, and it would be useful to add those @@ -2475,7 +2459,7 @@ entry: -
The following target-specific calling conventions are known to backend:
@@ -2494,7 +2478,7 @@ entry: Representing X86 addressing modes in MachineInstrs -The x86 has a very flexible way of accessing memory. It is capable of forming memory addresses of the following expression directly in integer @@ -2531,7 +2515,7 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg X86 address spaces supported -
x86 has a feature which provides the ability to perform loads and stores to different address spaces @@ -2576,7 +2560,7 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg Instruction naming -
An instruction name consists of the base name, a default operand size, and a a character per operand with an optional special size. For example:
@@ -2592,25 +2576,25 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memoryThe 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.
-LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC relative (PIC) or static addressing for accessing global values, so no TOC @@ -2630,7 +2614,7 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory Frame Layout -
The size of a PowerPC frame is usually fixed for the duration of a function's invocation. Since the frame is fixed size, all references @@ -2777,7 +2761,7 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory Prolog/Epilog -
The llvm prolog and epilog are the same as described in the PowerPC ABI, with the following exceptions. Callee saved registers are spilled after the frame @@ -2794,12 +2778,15 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory Dynamic Allocation -
TODO - More to come.
This document attempts to describe a few coding standards that are being used in the LLVM source tree. Although no coding standards should be regarded as @@ -122,17 +122,21 @@ href="mailto:sabre@nondot.org">Chris.
+Comments are one critical part of readability and maintainability. Everyone knows they should comment, so should you. When writing comments, write them as @@ -141,7 +145,9 @@ etc. Although we all should probably comment our code more than we do, there are a few very critical places that documentation is very useful:
-File Headers +Every source file should have a header on it that describes the basic purpose of the file. If a file does not have a header, it should not be @@ -184,7 +190,9 @@ Here it's only two lines. If an algorithm is being implemented or something tricky is going on, a reference to the paper where it is published should be included, as well as any notes or "gotchas" in the code to watch out for.
-Class overviews +Classes are one fundamental part of a good object oriented design. As such, a class definition should have a comment block that explains what the class is @@ -193,7 +201,9 @@ could figure it out, it's probably safe to leave it out. Naming classes something sane goes a long ways towards avoiding writing documentation.
-Method information +Methods defined in a class (as well as any global functions) should also be documented properly. A quick note about what it does and a description of the @@ -207,12 +217,14 @@ happens: does the method return null? Abort? Format your hard disk?
In general, prefer C++ style (//) comments. They take less space, require less typing, don't have nesting problems, etc. There are a few cases @@ -237,7 +249,7 @@ These nest properly and are better behaved in general than C style comments.
#include Style -Immediately after the header file comment (and include guards if working on a header file), the Source Code Width -
Write your code to fit within 80 columns of text. This helps those of us who like to print out code and look at your code in an xterm without resizing @@ -302,7 +314,7 @@ for debate.
Use Spaces Instead of Tabs -In all cases, prefer spaces to tabs in source files. People have different preferred indentation levels, and different styles of indentation that they @@ -323,7 +335,7 @@ makes for incredible diffs that are absolutely worthless.
Indent Code Consistently -Okay, in your first year of programming you were told that indentation is important. If you didn't believe and internalize this then, now is the time. @@ -331,19 +343,21 @@ Just do it.
If your code has compiler warnings in it, something is wrong — you aren't casting values correctly, your have "questionable" constructs in your @@ -397,7 +411,7 @@ be fixed by massaging the code appropriately.
Write Portable Code -In almost all cases, it is possible and within reason to write completely portable code. If there are cases where it isn't possible to write portable @@ -415,7 +429,7 @@ libSystem.
In an effort to reduce code and executable size, LLVM does not use RTTI (e.g. dynamic_cast<>) or exceptions. These two language features @@ -436,7 +450,7 @@ than dynamic_cast<>.
In C++, the class and struct keywords can be used almost interchangeably. The only difference is when they are used to declare a class: @@ -454,12 +468,17 @@ which case struct is allowed.
C++ doesn't do too well in the modularity department. There is no real encapsulation or data hiding (unless you use expensive protocol classes), but it @@ -503,7 +523,7 @@ translation unit.
#include as Little as Possible -#include hurts compile time performance. Don't do it unless you have to, especially in header files.
@@ -532,7 +552,7 @@ dependencies that you'll find out about later. Keep "Internal" Headers Private -Many modules have a complex implementation that causes them to use more than one implementation (.cpp) file. It is often tempting to put the @@ -553,7 +573,7 @@ class itself. Just make them private (or protected) and all is well.
Use Early Exits and continue to Simplify Code -When reading code, keep in mind how much state and how many previous decisions have to be remembered by the reader to understand a block of code. @@ -662,7 +682,7 @@ can be a big understandability win.
Don't use else after a return -For similar reasons above (reduction of indentation and easier reading), please do not use '