From 15ce1d71f1dca69eff13e5a56e3209558dcc1fc0 Mon Sep 17 00:00:00 2001 From: Dale Johannesen Date: Fri, 12 Feb 2010 23:16:24 +0000 Subject: [PATCH] Add the problem I just hacked around in 96015/96020. The solution there produces correct code, but is seriously deficient in several ways. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96039 91177308-0d34-0410-b5e6-96231b3b80d8 --- lib/Target/PowerPC/README.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/lib/Target/PowerPC/README.txt b/lib/Target/PowerPC/README.txt index 8f265cfc488..e49bda0fcd1 100644 --- a/lib/Target/PowerPC/README.txt +++ b/lib/Target/PowerPC/README.txt @@ -895,3 +895,20 @@ define double @test_FNEG_sel(double %A, double %B, double %C) { 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"); +}