* [PR63762]GCC generates UNPREDICTABLE STR with Rn = Rt for arm
@ 2014-11-18 11:31 Renlin Li
2014-11-18 20:48 ` Vladimir Makarov
0 siblings, 1 reply; 4+ messages in thread
From: Renlin Li @ 2014-11-18 11:31 UTC (permalink / raw)
To: gcc-patches; +Cc: Vladimir Makarov, ramana Radhakrishnan
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]
Hi all,
This patch should fix PR63762.
Hard_reg allocated during IRA pass conflicts with hard_reg allocated in
LRA pass because of inconsistent information between allocno and reg_pref.
The staled reg_class information in reg_pref is used by LRA while doing
hard register assignment. LRA makes wrong decision
to choose same hard_reg number for pseudo registers with overlapped
liveness.
For this particular case manifested on arm target:
(insn 180 183 184 15 (set (mem:SF (post_inc:SI (reg/v/f:SI 223 [ in ]))
[2 MEM[base: in_68, offset: 4294967292B]+0 S4 A32])
(reg/v:SF 290 [orig:224 val ] [224])) unpreditable-str.c:33 618
{*movsf_vfp}
(expr_list:REG_INC (reg/v/f:SI 223 [ in ])
(nil)))
IRA:
r290(2 ,SF, GENERAL_REGS) -> r278(2, SF, GENERAL_REGS) -> r224 (16, SF,
VFP_LO_REGS)
reg_pref[290] is set following its original_reg's(r224) info which is
VFP_LO_REGS.
LRA:
r302(SI, GENERAL_REGS) -> r223(SI, GENERAL_REGS)
while selecting hard register for r302, register class is checked first,
r290 is VFP_LO_REGS (from reg_pref[290]), r302 is GENERAL_REGS, so they
will never conflict. Thus, hard register number 2 is chosen for r302
without problem.
A testcase is added for all targets as I think it's a middle-end issue.
And sorry for not being able to simplify it.
arm-none-eabi has been test on the model, no new issues. bootstrapping
and regression tested on x86, no new issues.
Is it Okay to commit?
gcc/ChangeLog:
2014-11-18 Renlin Li <Renlin.Li@arm.com>
PR middle-end/63762
* ira.c (ira): Update preferred class.
gcc/testsuite/ChangeLog:
2014-11-18 Renlin Li <Renlin.Li@arm.com>
PR middle-end/63762
* gcc.dg/pr63762.c: New.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: new-7.diff --]
[-- Type: text/x-patch; name=new-7.diff, Size: 3461 bytes --]
diff --git a/gcc/ira.c b/gcc/ira.c
index 9c9e71d..e610d35 100644
--- a/gcc/ira.c
+++ b/gcc/ira.c
@@ -5263,7 +5263,18 @@ ira (FILE *f)
ira_allocno_iterator ai;
FOR_EACH_ALLOCNO (a, ai)
- ALLOCNO_REGNO (a) = REGNO (ALLOCNO_EMIT_DATA (a)->reg);
+ {
+ int old_regno = ALLOCNO_REGNO (a);
+ int new_regno = REGNO (ALLOCNO_EMIT_DATA (a)->reg);
+
+ ALLOCNO_REGNO (a) = new_regno;
+
+ if (old_regno != new_regno)
+ setup_reg_classes (new_regno, reg_preferred_class (old_regno),
+ reg_alternate_class (old_regno),
+ reg_allocno_class (old_regno));
+ }
+
}
else
{
diff --git a/gcc/testsuite/gcc.dg/pr63762.c b/gcc/testsuite/gcc.dg/pr63762.c
new file mode 100644
index 0000000..df11067
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr63762.c
@@ -0,0 +1,77 @@
+/* PR middle-end/63762 */
+/* { dg-do assemble } */
+/* { dg-options "-O2" } */
+
+#include <stdlib.h>
+
+void *astFree ();
+void *astMalloc ();
+void astNegate (void *);
+int astGetNegated (void *);
+void astGetRegionBounds (void *, double *, double *);
+int astResampleF (void *, ...);
+
+extern int astOK;
+
+int
+MaskF (int inside, int ndim, const int lbnd[], const int ubnd[],
+ float in[], float val)
+{
+
+ void *used_region;
+ float *c, *d, *out, *tmp_out;
+ double *lbndgd, *ubndgd;
+ int *lbndg, *ubndg, idim, ipix, nax, nin, nout, npix, npixg, result = 0;
+ if (!astOK) return result;
+ lbndg = astMalloc (sizeof (int)*(size_t) ndim);
+ ubndg = astMalloc (sizeof (int)*(size_t) ndim);
+ lbndgd = astMalloc (sizeof (double)*(size_t) ndim);
+ ubndgd = astMalloc (sizeof (double)*(size_t) ndim);
+ if (astOK)
+ {
+ astGetRegionBounds (used_region, lbndgd, ubndgd);
+ npix = 1;
+ npixg = 1;
+ for (idim = 0; idim < ndim; idim++)
+ {
+ lbndg[ idim ] = lbnd[ idim ];
+ ubndg[ idim ] = ubnd[ idim ];
+ npix *= (ubnd[ idim ] - lbnd[ idim ] + 1);
+ if (npixg >= 0) npixg *= (ubndg[ idim ] - lbndg[ idim ] + 1);
+ }
+ if (npixg <= 0 && astOK)
+ {
+ if ((inside != 0) == (astGetNegated( used_region ) != 0))
+ {
+ c = in;
+ for (ipix = 0; ipix < npix; ipix++) *(c++) = val;
+ result = npix;
+ }
+ }
+ else if (npixg > 0 && astOK)
+ {
+ if ((inside != 0) == (astGetNegated (used_region) != 0))
+ {
+ tmp_out = astMalloc (sizeof (float)*(size_t) npix);
+ if (tmp_out)
+ {
+ c = tmp_out;
+ for (ipix = 0; ipix < npix; ipix++) *(c++) = val;
+ result = npix - npixg;
+ }
+ out = tmp_out;
+ }
+ else
+ {
+ tmp_out = NULL;
+ out = in;
+ }
+ if (inside) astNegate (used_region);
+ result += astResampleF (used_region, ndim, lbnd, ubnd, in, NULL,
+ NULL, NULL, 0, 0.0, 100, val, ndim,
+ lbnd, ubnd, lbndg, ubndg, out, NULL);
+ if (inside) astNegate (used_region);
+ }
+ }
+ return result;
+}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PR63762]GCC generates UNPREDICTABLE STR with Rn = Rt for arm
2014-11-18 11:31 [PR63762]GCC generates UNPREDICTABLE STR with Rn = Rt for arm Renlin Li
@ 2014-11-18 20:48 ` Vladimir Makarov
2014-11-19 16:16 ` Ramana Radhakrishnan
0 siblings, 1 reply; 4+ messages in thread
From: Vladimir Makarov @ 2014-11-18 20:48 UTC (permalink / raw)
To: Renlin Li, gcc-patches; +Cc: ramana Radhakrishnan
On 11/18/2014 05:56 AM, Renlin Li wrote:
> Hi all,
>
> This patch should fix PR63762.
>
> Hard_reg allocated during IRA pass conflicts with hard_reg allocated
> in LRA pass because of inconsistent information between allocno and
> reg_pref.
>
> The staled reg_class information in reg_pref is used by LRA while
> doing hard register assignment. LRA makes wrong decision
> to choose same hard_reg number for pseudo registers with overlapped
> liveness.
>
>
> For this particular case manifested on arm target:
>
> (insn 180 183 184 15 (set (mem:SF (post_inc:SI (reg/v/f:SI 223 [ in
> ])) [2 MEM[base: in_68, offset: 4294967292B]+0 S4 A32])
> (reg/v:SF 290 [orig:224 val ] [224])) unpreditable-str.c:33
> 618 {*movsf_vfp}
> (expr_list:REG_INC (reg/v/f:SI 223 [ in ])
> (nil)))
>
> IRA:
> r290(2 ,SF, GENERAL_REGS) -> r278(2, SF, GENERAL_REGS) -> r224 (16,
> SF, VFP_LO_REGS)
> reg_pref[290] is set following its original_reg's(r224) info which is
> VFP_LO_REGS.
>
> LRA:
> r302(SI, GENERAL_REGS) -> r223(SI, GENERAL_REGS)
>
> while selecting hard register for r302, register class is checked
> first, r290 is VFP_LO_REGS (from reg_pref[290]), r302 is GENERAL_REGS,
> so they will never conflict. Thus, hard register number 2 is chosen
> for r302 without problem.
>
>
>
> A testcase is added for all targets as I think it's a middle-end
> issue. And sorry for not being able to simplify it.
> arm-none-eabi has been test on the model, no new issues. bootstrapping
> and regression tested on x86, no new issues.
>
> Is it Okay to commit?
Yes. Thanks very much for working on it and fixing it.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PR63762]GCC generates UNPREDICTABLE STR with Rn = Rt for arm
2014-11-18 20:48 ` Vladimir Makarov
@ 2014-11-19 16:16 ` Ramana Radhakrishnan
2014-11-19 16:32 ` Renlin Li
0 siblings, 1 reply; 4+ messages in thread
From: Ramana Radhakrishnan @ 2014-11-19 16:16 UTC (permalink / raw)
To: Vladimir Makarov, Renlin Li, gcc-patches
>> A testcase is added for all targets as I think it's a middle-end
>> issue. And sorry for not being able to simplify it.
>> arm-none-eabi has been test on the model, no new issues. bootstrapping
>> and regression tested on x86, no new issues.
>>
>> Is it Okay to commit?
> Yes. Thanks very much for working on it and fixing it.
Isn't this something that should be considered for the 4.9 branch as the
bug was reported there ?
Ramana
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PR63762]GCC generates UNPREDICTABLE STR with Rn = Rt for arm
2014-11-19 16:16 ` Ramana Radhakrishnan
@ 2014-11-19 16:32 ` Renlin Li
0 siblings, 0 replies; 4+ messages in thread
From: Renlin Li @ 2014-11-19 16:32 UTC (permalink / raw)
To: Ramana Radhakrishnan, Vladimir Makarov, gcc-patches
On 19/11/14 16:01, Ramana Radhakrishnan wrote:
>>> A testcase is added for all targets as I think it's a middle-end
>>> issue. And sorry for not being able to simplify it.
>>> arm-none-eabi has been test on the model, no new issues. bootstrapping
>>> and regression tested on x86, no new issues.
>>>
>>> Is it Okay to commit?
>> Yes. Thanks very much for working on it and fixing it.
> Isn't this something that should be considered for the 4.9 branch as the
> bug was reported there ?
>
> Ramana
>
>>
Commit in the trunk:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217783
I will prepare a backport patch shortly.
Regards,
Renlin Li
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-11-19 16:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-18 11:31 [PR63762]GCC generates UNPREDICTABLE STR with Rn = Rt for arm Renlin Li
2014-11-18 20:48 ` Vladimir Makarov
2014-11-19 16:16 ` Ramana Radhakrishnan
2014-11-19 16:32 ` Renlin Li
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).