[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #7 from uros at gcc dot gnu dot org 2009-01-25 12:26 --- Subject: Bug 38879 Author: uros Date: Sun Jan 25 12:26:15 2009 New Revision: 143663 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143663 Log: Backport from mainline: 2009-01-22 Uros Bizjak ubiz...@gmail.com PR target/38931 * config/i386/i386.md (*movsi_1): Use type mmx for alternative 2. (*movdi_1_rex64): Use type mmx for alternative 5. 2009-01-21 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/38879 * alias.c (base_alias_check): Unaligned access via AND address can alias all surrounding object types except those with sizes equal or wider than the size of unaligned access. testsuite/ChangeLog: Backport from mainline: 2009-01-22 Uros Bizjak ubiz...@gmail.com PR target/38931 * gcc.target/i386/pr38931.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr38931.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/alias.c branches/gcc-4_3-branch/gcc/config/i386/i386.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #8 from ubizjak at gmail dot com 2009-01-25 12:28 --- Backported to 4.3 branch. -- ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|4.4.0 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #5 from uros at gcc dot gnu dot org 2009-01-21 18:47 --- Subject: Bug 38879 Author: uros Date: Wed Jan 21 18:47:19 2009 New Revision: 143549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143549 Log: PR rtl-optimization/38879 * alias.c (base_alias_check): Unaligned access via AND address can alias all surrounding object types except those with sizes equal or wider than the size of unaligned access. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #6 from ubizjak at gmail dot com 2009-01-21 18:50 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #4 from ubizjak at gmail dot com 2009-01-20 19:49 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01018.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||01/msg01018.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #1 from ubizjak at gmail dot com 2009-01-17 17:04 ---
The problem is in a thinko in alias.c, base_alias_check (). For our problematic
addresses, we enter base_alias_check with:
x = (reg:DI 18 $18 [ i ])
and
y = (and:DI (reg/f:DI 16 $16 [orig:69 __result ] [69])
(const_int -8 [0xfff8]))
We actually have the code that handles this situation, just after the comment:
/* The base addresses of the read and write are different expressions.
If they are both symbols and they are not accessed via AND, there is
no conflict. We can bring knowledge of object alignment into play
here. For example, on alpha, char a, b; can alias one another,
though char a; long b; cannot. */
At the start of this code, we have:
base_x = (address (reg:DI 18 $18))
and
base_y = (address (reg:DI 16 $16))
These RTXes should trigger the code that analyses addresses involving AND
operation. So, actually we have to reverse the guarding condition!
Following patch fixes the failure:
--cut here--
Index: alias.c
===
--- alias.c (revision 143461)
+++ alias.c (working copy)
@@ -1527,7 +1527,7 @@ base_alias_check (rtx x, rtx y, enum mac
no conflict. We can bring knowledge of object alignment into play
here. For example, on alpha, char a, b; can alias one another,
though char a; long b; cannot. */
- if (GET_CODE (x_base) != ADDRESS GET_CODE (y_base) != ADDRESS)
+ if (GET_CODE (x_base) == ADDRESS || GET_CODE (y_base) == ADDRESS)
{
if (GET_CODE (x) == AND GET_CODE (y) == AND)
return 1;
--cut here--
Now, the scheduler creates correct schedule:
;; 12--17 $7=$17|$8 :(ev4_ib0+ev4_ebox)
;; 13--21 $4=unspec[$7,0x40,$16] 2 :(ev4_ib0+ev4_ebox)
;; 14--22 $5=$7$160x3 :(ev4_ib0+ev4_ebox)
;; 15--25 $3=$6|$4 :(ev4_ib0+ev4_ebox)
;; 15--27 [$16+0x70xfff8]=$3 :(ev4_ib1+ev4_abox)
;; 16--26 $0=$2|$5 :(ev4_ib0+ev4_ebox)
;; 16--28 [$160xfff8]=$0 :(ev4_ib1+ev4_abox)
;; 17--30 [$18]=$1 :(ev4_ib1+ev4_abox)
;; 18--45 return
:(ev4_ib1+ev4_bbox),ev4_bbox
And the asm is correct:
w_:
.frame $30,0,$26,0
ldah $29,0($27) !gpdisp!1
lda $29,0($29) !gpdisp!1
$w_..ng:
.prologue 1
ldah $25,$LC0($29) !gprelhigh
cpys $f31,$f31,$f31
lda $22,$LC0($25) !gprellow
ldq_u $21,7($16)
and $22,7,$20
ldq_u $24,$LC0($25) !gprellow
ldq_u $23,7($22)
bis $31,$31,$31
mskqh $21,$16,$6
ldq_u $19,0($16)
extql $24,$22,$17
extqh $23,$22,$8
mskql $19,$16,$2
cmoveq $20,0,$8
lda $1,8($31)
bis $17,$8,$7
insqh $7,$16,$4
insql $7,$16,$5
bis $6,$4,$3
stq_u $3,7($16)
bis $2,$5,$0
stq_u $0,0($16)
stl $1,0($18)
ret $31,($26),1
.end w_
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-01-17 17:04:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-17 18:05 --- That code is ancient, and wrong from day 1 if your analysis is correct :-) http://gcc.gnu.org/viewcvs/trunk/gcc/alias.c?r1=21967r2=23060 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #3 from ubizjak at gmail dot com 2009-01-17 18:40 ---
(In reply to comment #2)
That code is ancient, and wrong from day 1 if your analysis is correct :-)
Hm, no. The code is correct, but applies only to symbols involving ANDs.
We need somehing like this code also for the case when one of operands is
non-symbol and the other involves AND. I'm testing following patch:
--cut here--
Index: alias.c
===
--- alias.c (revision 143461)
+++ alias.c (working copy)
@@ -1543,6 +1543,20 @@ base_alias_check (rtx x, rtx y, enum mac
return 0;
}
+ if (GET_CODE (x_base) == ADDRESS || GET_CODE (y_base) == ADDRESS)
+{
+ if (GET_CODE (x) == AND GET_CODE (y) == AND)
+ return 1;
+ if (GET_CODE (x) == AND
+ (GET_CODE (XEXP (x, 1)) != CONST_INT
+ || (int) GET_MODE_UNIT_SIZE (y_mode) -INTVAL (XEXP (x, 1
+ return 1;
+ if (GET_CODE (y) == AND
+ (GET_CODE (XEXP (y, 1)) != CONST_INT
+ || (int) GET_MODE_UNIT_SIZE (x_mode) -INTVAL (XEXP (y, 1
+ return 1;
+}
+
/* If one address is a stack reference there can be no alias:
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
