Add information about memory index representation

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@4712 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 26 insertions, 1 deletions

diff --git a/lib/Target/X86/README.txt b/lib/Target/X86/README.txt
index 99d2e8e..b5101e4 100644
--- a/lib/Target/X86/README.txt
+++ b/lib/Target/X86/README.txt
@@ -128,8 +128,33 @@ This directory contains regression tests for the JIT.  Initially it contains a
 bunch of really trivial testcases that we should build up to supporting.
 
 
+===================================================
+IV. Strange Things, or, Things That Should Be Known
+===================================================
+
+Representing memory in MachineInstrs
+------------------------------------
+
+The x86 has a very, uhm, flexible, way of accessing memory.  It is capable of
+addressing memory addresses of the following form directly in integer
+instructions (which use ModR/M addressing):
+
+   Base+[1,2,4,8]*IndexReg+Disp32
+
+Wow, that's crazy.  In order to represent this, LLVM tracks no less that 4
+operands for each memory operand of this form.  This means that the "load" form
+of 'mov' has the following "Operands" in this order:
+
+Index:        0     |    1        2       3           4
+Meaning:   DestReg, | BaseReg,  Scale, IndexReg, Displacement
+OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm
+
+Stores and all other instructions treat the four memory operands in the same
+way, in the same order.
+
+
 ==========================
-IV. TODO / Future Projects
+V. TODO / Future Projects
 ==========================
 
 There are a large number of things remaining to do.  Here is a partial list: