+Note that there is some amount of complexity that the X86 backend contains due
+to the Sparc backend's legacy requirements. These should eventually fade away
+as the project progresses.
+
+
+SSA Instruction Representation
+------------------------------
+Target machine instructions are represented as instances of MachineInstr, and
+all specific machine instruction types should have an entry in the
+InstructionInfo table defined through X86InstrInfo.def. In the X86 backend,
+there are two particularly interesting forms of machine instruction: those that
+produce a value (such as add), and those that do not (such as a store).
+
+Instructions that produce a value use Operand #0 as the "destination" register.
+When printing the assembly code with the built-in machine instruction printer,
+these destination registers will be printed to the left side of an '=' sign, as
+in: %reg1027 = addl %reg1026, %reg1025
+
+This 'addl' MachineInstruction contains three "operands": the first is the
+destination register (#1027), the second is the first source register (#1026)
+and the third is the second source register (#1025). Never forget the
+destination register will show up in the MachineInstr operands vector. The code
+to generate this instruction looks like this:
+
+ BuildMI(BB, X86::ADDrr32, 2, 1027).addReg(1026).addReg(1025);
+
+The first argument to BuildMI is the basic block to append the machine
+instruction to, the second is the opcode, the third is the number of operands,
+the fourth is the destination register. The two addReg calls specify operands
+in order.
+
+MachineInstrs that do not produce a value do not have this implicit first
+operand, they simply have #operands = #uses. To create them, simply do not
+specify a destination register to the BuildMI call.
+
+
+======================================
+III. Lazy Function Resolution in Jello
+======================================
+
+Jello is a designed to be a JIT compiler for LLVM code. This implies that call
+instructions may be emitted before the function they call is compiled. In order
+to support this, Jello currently emits unresolved call instructions to call to a
+null pointer. When the call instruction is executed, a segmentation fault will
+be generated.
+
+Jello installs a trap handler for SIGSEGV, in order to trap these events. When
+a SIGSEGV occurs, first we check to see if it's due to lazy function resolution,
+if so, we look up the return address of the function call (which was pushed onto
+the stack by the call instruction). Given the return address of the call, we
+consult a map to figure out which function was supposed to be called from that
+location.
+
+If the function has not been code generated yet, it is at this time. Finally,
+the EIP of the process is modified to point to the real function address, the
+original call instruction is updated, and the SIGSEGV handler returns, causing
+execution to start in the called function. Because we update the original call
+instruction, we should only get at most one signal for each call site.
+
+Note that this approach does not work for indirect calls. The problem with
+indirect calls is that taking the address of a function would not cause a fault
+(it would simply copy null into a register), so we would only find out about the
+problem when the indirect call itself was made. At this point we would have no
+way of knowing what the intended function destination was. Because of this, we
+immediately code generate functions whenever they have their address taken,
+side-stepping the problem completely.
+
+
+======================
+IV. Source Code Layout
+======================