[llvm-commits] [llvm] r96039 - /llvm/trunk/lib/Target/PowerPC/README.txt

[Dale Johannesen]

Author: johannes
Date: Fri Feb 12 17:16:24 2010
New Revision: 96039

URL: http://llvm.org/viewvc/llvm-project?rev=96039&view=rev
Log:
Add the problem I just hacked around in 96015/96020.
The solution there produces correct code, but is seriously
deficient in several ways.


Modified:
    llvm/trunk/lib/Target/PowerPC/README.txt

Modified: llvm/trunk/lib/Target/PowerPC/README.txt
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/README.txt?rev=96039&r1=96038&r2=96039&view=diff

==============================================================================
--- llvm/trunk/lib/Target/PowerPC/README.txt (original)
+++ llvm/trunk/lib/Target/PowerPC/README.txt Fri Feb 12 17:16:24 2010
@@ -895,3 +895,20 @@
         ret double %E
 }
 
+//===----------------------------------------------------------------------===//
+The save/restore sequence for CR in prolog/epilog is terrible:
+- Each CR subreg is saved individually, rather than doing one save as a unit.
+- On Darwin, the save is done after the decrement of SP, which means the offset
+from SP of the save slot can be too big for a store instruction, which means we
+need an additional register (currently hacked in 96015+96020; the solution there
+is correct, but poor).
+- On SVR4 the same thing can happen, and I don't think saving before the SP
+decrement is safe on that target, as there is no red zone.  This is currently
+broken AFAIK, although it's not a target I can exercise.
+The following demonstrates the problem:
+extern void bar(char *p);
+void foo() {
+  char x[100000];
+  bar(x);
+  __asm__("" ::: "cr2");
+}