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