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.
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
