Revision: 126489
Author: clattner
Date: 2007-04-24 18:53:42 -0700 (Tue, 24 Apr 2007)
Log Message:
-----------
add it turns out, using "(((SIZE)/(ALIGN)) > (MOVE_RATIO))" as a decision of
whether or not to do a copy with scalar stores is an extremely bad idea. For
example, it turns the initializer in test/CFrontend/block-copy.c into 128
scalar stores (it is size 512 with alignment 32). Since this stuff is only
used by the gimplifier for CONSTRUCTOR lowering, force it to always use memcpy
when possible. This dramatically reduces the code size of some examples.
Modified Paths:
--------------
apple-local/branches/llvm/gcc/expr.c
Modified: apple-local/branches/llvm/gcc/expr.c
===================================================================
--- apple-local/branches/llvm/gcc/expr.c 2007-04-25 00:26:05 UTC (rev
126488)
+++ apple-local/branches/llvm/gcc/expr.c 2007-04-25 01:53:42 UTC (rev
126489)
@@ -175,16 +175,10 @@
/* APPLE LOCAL begin LLVM */
#ifdef ENABLE_LLVM
+/* LLVM always emits moves with memcpy, which allows us to make smart decisions
+ later. This affects CONSTRUCTOR lowering in the gimplifier. */
#undef MOVE_BY_PIECES_P
-#undef CLEAR_BY_PIECES_P
-#undef STORE_BY_PIECES_P
-
-/* Disable functions like move_by_pieces_ninsns which want to look at
- * optabs, which we do not initialize.
- */
-#define STORE_BY_PIECES_P(SIZE, ALIGN) (((SIZE)/(ALIGN)) > (MOVE_RATIO))
-#define CLEAR_BY_PIECES_P(SIZE, ALIGN) (((SIZE)/(ALIGN)) > (CLEAR_RATIO))
-#define MOVE_BY_PIECES_P(SIZE, ALIGN) (((SIZE)/(ALIGN)) > (MOVE_RATIO))
+#define MOVE_BY_PIECES_P(SIZE, ALIGN) ((SIZE-SIZE)+(ALIGN-ALIGN))
#endif
/* APPLE LOCAL end LLVM */
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
