From fe4c7fb7ae934d1d2edf51b9ca762d378e2a2b77 Mon Sep 17 00:00:00 2001
From: Chris Lattner <sabre@nondot.org>
Date: Mon, 13 Mar 2006 06:52:22 +0000
Subject: [PATCH] remove two implemented items

llvm-svn: 26728
---
 llvm/lib/Target/README.txt | 22 ----------------------
 1 file changed, 22 deletions(-)

diff --git a/llvm/lib/Target/README.txt b/llvm/lib/Target/README.txt
index 220bd9e5208c..a28486091cbc 100644
--- a/llvm/lib/Target/README.txt
+++ b/llvm/lib/Target/README.txt
@@ -56,20 +56,6 @@ Number 1 is the preferred solution.
 
 //===---------------------------------------------------------------------===//
 
-DAG combine this into mul A, 8:
-
-int %test(int %A) {
-  %B = mul int %A, 8  ;; shift
-  %C = add int %B, 7  ;; dead, no demanded bits.
-  %D = and int %C, -8 ;; dead once add is gone.
-  ret int %D
-}
-
-This sort of thing occurs in the alloca lowering code and other places that
-are generating alignment of an already aligned value.
-
-//===---------------------------------------------------------------------===//
-
 Turn this into a signed shift right in instcombine:
 
 int f(unsigned x) {
@@ -81,14 +67,6 @@ http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01492.html
 
 //===---------------------------------------------------------------------===//
 
-We should reassociate:
-int f(int a, int b){ return a * a + 2 * a * b + b * b; }
-into:
-int f(int a, int b) { return a * (a + 2 * b) + b * b; }
-to eliminate a multiply.
-
-//===---------------------------------------------------------------------===//
-
 On targets with expensive 64-bit multiply, we could LSR this:
 
 for (i = ...; ++i) {