epiphany.h (USE_LOAD_POST_INCREMENT): Define.

* config/epiphany/epiphany.h (USE_LOAD_POST_INCREMENT): Define.
        (USE_LOAD_POST_DECREMENT, USE_STORE_POST_INCREMENT): Likewise.
        (USE_STORE_POST_DECREMENT): Likewise.

From-SVN: r182185
This commit is contained in:
Joern Rennecke 2011-12-10 09:40:02 +00:00 committed by Joern Rennecke
parent 2ac69a0c6c
commit af7476b83d
2 changed files with 21 additions and 0 deletions

View File

@ -1,3 +1,9 @@
2011-12-10 Joern Rennecke <joern.rennecke@embecosm.com>
* config/epiphany/epiphany.h (USE_LOAD_POST_INCREMENT): Define.
(USE_LOAD_POST_DECREMENT, USE_STORE_POST_INCREMENT): Likewise.
(USE_STORE_POST_DECREMENT): Likewise.
2011-12-10 Nathan Sidwell <nathan@acm.org>
PR gcov-profile/51449

View File

@ -602,6 +602,21 @@ typedef struct GTY (()) machine_function
#define HAVE_POST_MODIFY_DISP TARGET_POST_MODIFY
#define HAVE_POST_MODIFY_REG TARGET_POST_MODIFY
/* Currently, the only users of the USE_*CREMENT macros are
move_by_pieces / store_by_pieces_1 . We don't want them to use
POST_MODIFY modes, because we got ample addressing range for the
reg+offset addressing mode; besides, there are short index+offset loads,
but the only short post-modify load uses POST_MODIFY_REG.
Moreover, using auto-increment in move_by_pieces from structure copying
in the prologue causes confused debug output.
If another pass starts using these macros where the use of these
addressing modes would make more sense, we can try checking the
current pass. */
#define USE_LOAD_POST_INCREMENT(MODE) 0
#define USE_LOAD_POST_DECREMENT(MODE) 0
#define USE_STORE_POST_INCREMENT(MODE) 0
#define USE_STORE_POST_DECREMENT(MODE) 0
/* Recognize any constant value that is a valid address. */
#define CONSTANT_ADDRESS_P(X) \
(GET_CODE (X) == LABEL_REF || GET_CODE (X) == SYMBOL_REF \