This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()
- From: Jeff Law <law at redhat dot com>
- To: Chen Gang S <gang dot chen at sunrus dot com dot cn>, Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: augustine dot sterling at gmail dot com, "Joseph S. Myers" <joseph at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 24 Feb 2015 08:54:54 -0700
- Subject: Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()
- Authentication-results: sourceware.org; auth=none
- References: <54E99B0E dot 2080109 at sunrus dot com dot cn> <54EBA926 dot 30207 at redhat dot com> <CABu31nPrpNmLQapXcu_XF0S12DKM27eVrTJ9GER=eN6oo=L7VA at mail dot gmail dot com> <54EBB454 dot 9000601 at redhat dot com> <54EBD4ED dot 4080605 at sunrus dot com dot cn>
On 02/23/15 18:33, Chen Gang S wrote:
On 2/24/15 07:14, Jeff Law wrote:
On 02/23/15 16:09, Steven Bosscher wrote:
Which violate the rule for matching constraints.
...and should never have worked at all...
Yup. It's only been fairly recently that we started statically
checking MD files in any significant way -- we've still got a long
way to go I'm sure.
OK, thanks. I shall try to finish within this month (although I am
not quite sure whether I can finish on time).
No problem. Any contribution you can make in this area is appreciated.
OK, thanks. May I firstly finish it before fixing xtensa pattern? I
guess it is more easier than fixing xtensa patten. (I guess 'warming'
is 'warning'.)
You can tackle them in any order you wish. However, I suspect fixing
the xtensa backend may be easier. I don't have any good way to test
xtensa, but something like the attached patch for the xtensa port should
be sufficient.
By the way, can this patch "initialize several arrays before use them
in find_reloads()" will cause correctness issue? (I guess not, it
will skip optimization, but not cause correctness issue, and continue
compiling).
It will not cause any correctness issues, but it will cause
unwanted/unnecessary initialization of those arrays each time we enter
that function.
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index 9c2afad..ccaa2b2 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -1290,11 +1290,11 @@
(define_insn "zero_cost_loop_start"
[(set (pc)
- (if_then_else (ne (match_operand:SI 0 "register_operand" "2")
+ (if_then_else (ne (match_operand:SI 2 "register_operand" "0")
(const_int 1))
(label_ref (match_operand 1 "" ""))
(pc)))
- (set (match_operand:SI 2 "register_operand" "=a")
+ (set (match_operand:SI 0 "register_operand" "=a")
(plus (match_dup 0)
(const_int -1)))
(unspec [(const_int 0)] UNSPEC_LSETUP_START)]
@@ -1306,11 +1306,11 @@
(define_insn "zero_cost_loop_end"
[(set (pc)
- (if_then_else (ne (match_operand:SI 0 "nonimmediate_operand" "2,2")
+ (if_then_else (ne (match_operand:SI 2 "nonimmediate_operand" "0,0")
(const_int 1))
(label_ref (match_operand 1 "" ""))
(pc)))
- (set (match_operand:SI 2 "nonimmediate_operand" "=a,m")
+ (set (match_operand:SI 0 "nonimmediate_operand" "=a,m")
(plus (match_dup 0)
(const_int -1)))
(unspec [(const_int 0)] UNSPEC_LSETUP_END)
@@ -1323,11 +1323,11 @@
(define_insn "loop_end"
[(set (pc)
- (if_then_else (ne (match_operand:SI 0 "register_operand" "2")
+ (if_then_else (ne (match_operand:SI 2 "register_operand" "0")
(const_int 1))
(label_ref (match_operand 1 "" ""))
(pc)))
- (set (match_operand:SI 2 "register_operand" "=a")
+ (set (match_operand:SI 0 "register_operand" "=a")
(plus (match_dup 0)
(const_int -1)))
(unspec [(const_int 0)] UNSPEC_LSETUP_END)]