| Message ID | 55FAEB28.9020901@arm.com |
|---|---|
| State | Accepted |
| Commit | 470512c31b5e078519370ce66fb39a3b6d604392 |
| Headers | show |
Hi Kyrill, > Bootstrapped and tested on aarch64 and x86_64. > Rainer, could you please try this patch in combination with the one I sent > earlier at: > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html will do, however, Solaris/SPARC bootstrap is broken right now (PR bootstrap/67622) and I'll have to hunt that down first. Rainer
Hi Kyrill, > Bootstrapped and tested on aarch64 and x86_64. > Rainer, could you please try this patch in combination with the one I sent > earlier at: > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html it took me quite a bit, but I've now regtested those two patches: with them both applied, the sparc-sun-solaris2.12 build succeeds and the two gcc.c-torture/execute/20071216-1.c failures are gone. So, from a SPARC POV the patches are good to go. Thanks. Rainer
Hi Rainer, On 25/09/15 11:57, Rainer Orth wrote: > Hi Kyrill, > >> Bootstrapped and tested on aarch64 and x86_64. >> Rainer, could you please try this patch in combination with the one I sent >> earlier at: >> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html > it took me quite a bit, but I've now regtested those two patches: with > them both applied, the sparc-sun-solaris2.12 build succeeds and the two > gcc.c-torture/execute/20071216-1.c failures are gone. > > So, from a SPARC POV the patches are good to go. Phew, thanks a lot! So, in conclusion the patches I'd like approval for are: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01306.html and https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html Kyrill > > Thanks. > Rainer >
On 09/25/2015 05:06 AM, Kyrill Tkachov wrote: > Hi Rainer, > > On 25/09/15 11:57, Rainer Orth wrote: >> Hi Kyrill, >> >>> Bootstrapped and tested on aarch64 and x86_64. >>> Rainer, could you please try this patch in combination with the one I >>> sent >>> earlier at: >>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html >> it took me quite a bit, but I've now regtested those two patches: with >> them both applied, the sparc-sun-solaris2.12 build succeeds and the two >> gcc.c-torture/execute/20071216-1.c failures are gone. >> >> So, from a SPARC POV the patches are good to go. > > Phew, thanks a lot! > > So, in conclusion the patches I'd like approval for are: > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01306.html > and > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html These are OK. Thanks for taking the time to work with Rainer and sort out the sparc issues. It's greatly appreciated. Jeff
On 25/09/15 21:03, Jeff Law wrote: > On 09/25/2015 05:06 AM, Kyrill Tkachov wrote: >> Hi Rainer, >> >> On 25/09/15 11:57, Rainer Orth wrote: >>> Hi Kyrill, >>> >>>> Bootstrapped and tested on aarch64 and x86_64. >>>> Rainer, could you please try this patch in combination with the one I >>>> sent >>>> earlier at: >>>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html >>> it took me quite a bit, but I've now regtested those two patches: with >>> them both applied, the sparc-sun-solaris2.12 build succeeds and the two >>> gcc.c-torture/execute/20071216-1.c failures are gone. >>> >>> So, from a SPARC POV the patches are good to go. >> Phew, thanks a lot! >> >> So, in conclusion the patches I'd like approval for are: >> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01306.html >> and >> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html > These are OK. Thanks for taking the time to work with Rainer and sort > out the sparc issues. It's greatly appreciated. No problem, they were my regressions to fix after all, and it's easier to fix now rather than in stage3/4. I've committed them with r228194 and r228195. Thanks, Kyrill > Jeff >
On Mon, Sep 28, 2015 at 1:26 AM, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote: > > On 25/09/15 21:03, Jeff Law wrote: >> >> On 09/25/2015 05:06 AM, Kyrill Tkachov wrote: >>> >>> Hi Rainer, >>> >>> On 25/09/15 11:57, Rainer Orth wrote: >>>> >>>> Hi Kyrill, >>>> >>>>> Bootstrapped and tested on aarch64 and x86_64. >>>>> Rainer, could you please try this patch in combination with the one I >>>>> sent >>>>> earlier at: >>>>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html >>>> >>>> it took me quite a bit, but I've now regtested those two patches: with >>>> them both applied, the sparc-sun-solaris2.12 build succeeds and the two >>>> gcc.c-torture/execute/20071216-1.c failures are gone. >>>> >>>> So, from a SPARC POV the patches are good to go. >>> >>> Phew, thanks a lot! >>> >>> So, in conclusion the patches I'd like approval for are: >>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01306.html >>> and >>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00815.html >> >> These are OK. Thanks for taking the time to work with Rainer and sort >> out the sparc issues. It's greatly appreciated. > > > No problem, they were my regressions to fix after all, and it's easier to > fix now rather than in stage3/4. > > I've committed them with r228194 and r228195. > This caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67749
commit 9c327def49735ab179b68f2301fc4623ee45c974
Author: Kyrylo Tkachov <kyrylo.tkachov@arm.com>
Date: Mon Sep 7 14:58:01 2015 +0100
[RTL-ifcvt] PR rtl-optimization/67465: Do not ifcvt complex blocks if the else block is empty
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 1e773d8..5b133f1 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -2038,6 +2038,11 @@ noce_try_cmove_arith (struct noce_if_info *if_info)
insn_a = if_info->insn_a;
insn_b = if_info->insn_b;
+ machine_mode x_mode = GET_MODE (x);
+
+ if (!can_conditionally_move_p (x_mode))
+ return FALSE;
+
unsigned int then_cost;
unsigned int else_cost;
if (insn_a)
@@ -2074,13 +2079,38 @@ noce_try_cmove_arith (struct noce_if_info *if_info)
}
}
- if (!a_simple && then_bb && !b_simple && else_bb
+ if (then_bb && else_bb && !a_simple && !b_simple
&& (!bbs_ok_for_cmove_arith (then_bb, else_bb)
|| !bbs_ok_for_cmove_arith (else_bb, then_bb)))
return FALSE;
start_sequence ();
+ /* If one of the blocks is empty then the corresponding B or A value
+ came from the test block. The non-empty complex block that we will
+ emit might clobber the register used by B or A, so move it to a pseudo
+ first. */
+
+ if (b_simple || !else_bb)
+ {
+ rtx tmp_b = gen_reg_rtx (x_mode);
+ /* Perform the simplest kind of set. The register allocator
+ should remove it if it's not actually needed. If this set is not
+ a valid insn (can happen on the is_mem path) then end_ifcvt_sequence
+ will cancel the whole sequence. Don't try any of the fallback paths
+ from noce_emit_move_insn since we want this to be the simplest kind
+ of move. */
+ emit_insn (gen_rtx_SET (tmp_b, b));
+ b = tmp_b;
+ }
+
+ if (a_simple || !then_bb)
+ {
+ rtx tmp_a = gen_reg_rtx (x_mode);
+ emit_insn (gen_rtx_SET (tmp_a, a));
+ a = tmp_a;
+ }
+
orig_a = a;
orig_b = b;
diff --git a/gcc/testsuite/gcc.dg/pr67465.c b/gcc/testsuite/gcc.dg/pr67465.c
new file mode 100644
index 0000000..321fd38
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr67465.c
@@ -0,0 +1,53 @@
+/* { dg-do run } */
+/* { dg-options "-O3 -std=gnu99" } */
+
+int a, b, c, d, e, h;
+
+int
+fn1 (int p1)
+{
+ {
+ int g[2];
+ for (int i = 0; i < 1; i++)
+ g[i] = 0;
+ if (g[0] < c)
+ {
+ a = (unsigned) (1 ^ p1) % 2;
+ return 0;
+ }
+ }
+ return 0;
+}
+
+void
+fn2 ()
+{
+ for (h = 0; h < 1; h++)
+ {
+ for (int j = 0; j < 2; j++)
+ {
+ for (b = 1; b; b = 0)
+ a = 1;
+ for (; b < 1; b++)
+ ;
+ if (e)
+ continue;
+ a = 2;
+ }
+ fn1 (h);
+ short k = -16;
+ d = k > a;
+ }
+}
+
+int
+main ()
+{
+ fn2 ();
+
+ if (a != 2)
+ __builtin_abort ();
+
+ return 0;
+}
+