[llvm-commits] CVS: llvm/lib/Target/X86/README.txt

[Evan Cheng]

Changes in directory llvm/lib/Target/X86:

README.txt updated: 1.145 -> 1.146
---
Log message:

New entries.

---
Diffs of the changes:  (+20 -0)

 README.txt |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+)


Index: llvm/lib/Target/X86/README.txt
diff -u llvm/lib/Target/X86/README.txt:1.145 llvm/lib/Target/X86/README.txt:1.146
--- llvm/lib/Target/X86/README.txt:1.145	Tue Nov 14 02:08:46 2006
+++ llvm/lib/Target/X86/README.txt	Tue Nov 28 13:59:25 2006
@@ -730,3 +730,23 @@
 except that mul isn't a commutative 2-addr instruction.  I guess this has
 to be done at isel time based on the #uses to mul?
 
+//===---------------------------------------------------------------------===//
+
+Make sure the instruction which starts a loop does not cross a cacheline
+boundary. This requires knowning the exact length of each machine instruction.
+That is somewhat complicated, but doable. Example 256.bzip2:
+
+In the new trace, the hot loop has an instruction which crosses a cacheline
+boundary.  In addition to potential cache misses, this can't help decoding as I
+imagine there has to be some kind of complicated decoder reset and realignment
+to grab the bytes from the next cacheline.
+
+532  532 0x3cfc movb     (1809(%esp, %esi), %bl   <<<--- spans 2 64 byte lines
+942  942 0x3d03 movl     %dh, (1809(%esp, %esi)                                                                          
+937  937 0x3d0a incl     %esi                           
+3    3   0x3d0b cmpb     %bl, %dl                                               
+27   27  0x3d0d jnz      0x000062db <main+11707>
+
+//===---------------------------------------------------------------------===//
+
+In c99 mode, the preprocessor doesn't like assembly comments like #TRUNCATE.