This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/36780] [4.3/4.4 Regression] Wrong reload generated for subreg address on SH
- From: "kkojima at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 10 Jul 2008 23:25:48 -0000
- Subject: [Bug target/36780] [4.3/4.4 Regression] Wrong reload generated for subreg address on SH
- References: <bug-36780-5208@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #2 from kkojima at gcc dot gnu dot org 2008-07-10 23:25 -------
First I've modified addsi3 pattern and added a splitter
(define_split
[(set (match_operand:SI 0 "arith_reg_dest" "")
(plus:SI (match_operand:SI 1 "arith_operand" "")
(match_operand:SI 2 "arith_operand" "")))]
"TARGET_SH1 && reload_completed && !rtx_equal_p (operands[0], operands[1])"
[(set (match_dup 0) (match_dup 2))
(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 1)))]
"")
This fixes the build failure but there are many regressions
at -O0. It seems that the reload in problem makes very complex
reloads on this backend and some another latent problems are
revealed. I've tried to see what is going on for these cases
for a while and then given up.
When looking into these complex reloads, I've noticed that
the address having the type (plus (plus reg const_int) const_int)
is cared about specially in LEGITIMIZE_RELOAD_ADDRESS in this
backend. I've tried to add the corresponding code in
GO_IF_LEGITIMATE_ADDRESS so that strict_memory_address_p can
recognize the above address expression when reloading.
It fixes the build failure and there are no major regressions
with it. Although this is clearly a workaround and the issue
should be looking more deeply, I guess this will be ok at this
point, especially for the 4.3-branch which will schedule
the 4.3.2 release in a month.
Now I'm testing the patch below for 4.3/4.4 in native environments:
--- ORIG/trunk/gcc/config/sh/sh.h 2008-07-06 09:31:18.000000000 +0900
+++ LOCAL/trunk/gcc/config/sh/sh.h 2008-07-10 13:58:40.000000000 +0900
@@ -2501,6 +2501,18 @@ struct sh_args {
goto LABEL; \
} \
} \
+ /* When reload in progress, find_reloads_subreg_address tries to \
+ make a new reload for some types of address. Unfortunately it \
+ generates wrong code on SH. See PR36780. The following is to \
+ avoid this issue. */ \
+ if (!TARGET_SHMEDIA && reload_in_progress \
+ && GET_CODE (X) == PLUS \
+ && (GET_MODE_SIZE (MODE) == 4 || GET_MODE_SIZE (MODE) == 8) \
+ && GET_CODE (XEXP ((X), 0)) == PLUS \
+ && GET_CODE (XEXP (XEXP ((X), 0), 1)) == CONST_INT \
+ && BASE_REGISTER_RTX_P (XEXP (XEXP ((X), 0), 0)) \
+ && GET_CODE (XEXP ((X), 1)) == CONST_INT)
\
+ goto LABEL;
\
}
/* Try machine-dependent ways of modifying an illegitimate address
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36780