https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jamborm at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On this testcase, the only case (2 times) where operand_equal_p returns 1 on
*MEM_REF even when !types_compatible_p (TREE_TYPE (arg0), TREE_TYPE (arg1))
is during predcom, one argument is the whole a:
<mem_ref 0x7ffff1858460
type <array_type 0x7ffff18173f0
type <record_type 0x7ffff18171f8 S sizes-gimplified type_0 DI
size <integer_cst 0x7ffff1713ca8 constant 64>
unit size <integer_cst 0x7ffff1713cc0 constant 8>
align 32 symtab 0 alias set 2 canonical type 0x7ffff18171f8 fields
<field_decl 0x7ffff1736da8 f> context <translation_unit_decl 0x7ffff171f258
D.1772>
pointer_to_this <pointer_type 0x7ffff1817498> chain <type_decl
0x7ffff1736d10 D.1755>>
DI size <integer_cst 0x7ffff1713ca8 64> unit size <integer_cst
0x7ffff1713cc0 8>
align 32 symtab 0 alias set 2 canonical type 0x7ffff18173f0
domain <integer_type 0x7ffff1735930 type <integer_type 0x7ffff17171f8
sizetype>
DI size <integer_cst 0x7ffff1713ca8 64> unit size <integer_cst
0x7ffff1713cc0 8>
align 64 symtab 0 alias set -1 canonical type 0x7ffff1735930
precision 64 min <integer_cst 0x7ffff1713cd8 0> max <integer_cst 0x7ffff1713cd8
0>>
pointer_to_this <pointer_type 0x7ffff183f3f0>>
arg 0 <addr_expr 0x7ffff1857f40
type <pointer_type 0x7ffff183f3f0 type <array_type 0x7ffff18173f0>
public unsigned DI size <integer_cst 0x7ffff1713ca8 64> unit size
<integer_cst 0x7ffff1713cc0 8>
align 64 symtab 0 alias set -1 canonical type 0x7ffff183f3f0>
constant
arg 0 <var_decl 0x7ffff7ff9cf0 a type <array_type 0x7ffff18173f0>
used public static common DI file pr70127.c line 1 col 39 size
<integer_cst 0x7ffff1713ca8 64> unit size <integer_cst 0x7ffff1713cc0 8>
align 32 context <translation_unit_decl 0x7ffff171f258 D.1772>
chain <var_decl 0x7ffff7ff9d80 c>>>
arg 1 <integer_cst 0x7ffff1827660 type <pointer_type 0x7ffff183f3f0>
constant 0>>
and the other one its first element:
<mem_ref 0x7ffff1843b68
type <record_type 0x7ffff18171f8 S sizes-gimplified type_0 DI
size <integer_cst 0x7ffff1713ca8 constant 64>
unit size <integer_cst 0x7ffff1713cc0 constant 8>
align 32 symtab 0 alias set 2 canonical type 0x7ffff18171f8
fields <field_decl 0x7ffff1736da8 f type <integer_type 0x7ffff17177e0
int>
SI file pr70127.c line 1 col 16
size <integer_cst 0x7ffff1713ee8 constant 32>
unit size <integer_cst 0x7ffff1713f00 constant 4>
align 32 offset_align 128
offset <integer_cst 0x7ffff1713cd8 constant 0>
bit offset <integer_cst 0x7ffff1713d20 constant 0> context
<record_type 0x7ffff18171f8 S> chain <field_decl 0x7ffff1736e40 g>> context
<translation_unit_decl 0x7ffff171f258 D.1772>
pointer_to_this <pointer_type 0x7ffff1817498> chain <type_decl
0x7ffff1736d10 D.1755>>
arg 0 <addr_expr 0x7ffff1850120
type <pointer_type 0x7ffff183f3f0 type <array_type 0x7ffff18173f0>
public unsigned DI size <integer_cst 0x7ffff1713ca8 64> unit size
<integer_cst 0x7ffff1713cc0 8>
align 64 symtab 0 alias set -1 canonical type 0x7ffff183f3f0>
constant
arg 0 <var_decl 0x7ffff7ff9cf0 a type <array_type 0x7ffff18173f0>
used public static common DI file pr70127.c line 1 col 39 size
<integer_cst 0x7ffff1713ca8 64> unit size <integer_cst 0x7ffff1713cc0 8>
align 32 context <translation_unit_decl 0x7ffff171f258 D.1772>
chain <var_decl 0x7ffff7ff9d80 c>>>
arg 1 <integer_cst 0x7ffff1827660 type <pointer_type 0x7ffff183f3f0>
constant 0>
pr70127.c:17:13 start: pr70127.c:17:11 finish: pr70127.c:17:22>
The first one is base object from
a[0] = c;
stmt and the second one from
e$g_20 = MEM[(struct S[1] *)&a].g;
(in the other call the first stmt is e = a[0]; and the second one is the same).
Looking at the tree dumps, I see weirdo behavior in early SRA (CCing Martin),
where it changes:
e.f = 1;
e.g = 1;
a[0] = c;
e = a[0];
d = e;
e ={v} {CLOBBER};
into:
e$f_4 = 1;
e$g_18 = 1;
a[0] = c;
e = a[0];
e$f_17 = MEM[(struct S[1] *)&a];
e$g_19 = MEM[(struct S[1] *)&a].g;
MEM[(struct S *)&e] = e$f_17;
e.g = e$g_19;
d = e;
e ={v} {CLOBBER};
(the weird thing is that e = a[0] assignment remains, and then it is done once
again for each element).
And then the effect of the (IMHO broken, but I haven't seen the IRC discussion
Honza refers to) operand_equal_p change in predcom is:
<bb 4>:
+ a__g_lsm0.13_36 = BIT_FIELD_REF <MEM[(struct S[1] *)&a + 4B], 2, 0>;
<bb 5>:
# prephitmp_16 = PHI <_24(4), _6(6)>
a[0] = c;
e = a[0];
e_1 = MEM[(struct S[1] *)&a];
- e$g_20 = MEM[(struct S[1] *)&a].g;
+ e$g_20 = a__g_lsm0.13_36;
MEM[(struct S *)&e] = e_1;
e.g = e$g_20;
d = e;
So, shall we revert the operand_equal_p change (wonder why the pr56635.C test
now passes?), or change initialize_data_dependence_relation to also check
types_compatible_p next to operand_equal_p, or change something in predcom?
What about the SRA case?
