[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|13.5|13.0 Resolution|--- |FIXED --- Comment #13 from Richard Biener --- This was fixed for GCC 13.
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.4|13.5 --- Comment #12 from Jakub Jelinek --- GCC 13.4 is being released, retargeting bugs to GCC 13.5.
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.3|13.4 --- Comment #11 from Jakub Jelinek --- GCC 13.3 is being released, retargeting bugs to GCC 13.4.
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 Richard Biener changed: What|Removed |Added Target Milestone|13.2|13.3 --- Comment #10 from Richard Biener --- GCC 13.2 is being released, retargeting bugs to GCC 13.3.
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 Richard Biener changed: What|Removed |Added Target Milestone|13.0|13.2 --- Comment #9 from Richard Biener --- GCC 13.1 is being released, retargeting bugs to GCC 13.2.
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 Martin Liška changed: What|Removed |Added CC||alastair.j.irving at gmail dot com --- Comment #8 from Martin Liška --- *** Bug 108074 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 Richard Biener changed: What|Removed |Added Target Milestone|12.0|13.0 Priority|P3 |P2
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 --- Comment #6 from Richard Biener --- Created attachment 52293 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52293&action=edit untested patch Like this - it unfortunately regresses the diagnostic case in PR99673 again but should leave early __builtin_object_size untouched.
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162
--- Comment #5 from Richard Biener ---
(In reply to Richard Biener from comment #4)
> Btw, in VN it would be nice to handle
>
> struct S { int i; };
>
> int i;
> int bar (char *p)
> {
> char *q = p + 1;
> i = 1;
> char *r = (char *)&(((struct S *)&p[i])->i);
> return q == r;
> }
Rather the following
struct S { int a[4]; };
int i;
int bar (struct S *p)
{
char *q = (char *)p + 4;
i = 1;
int *r = &((struct S *)p)->a[i];
return q == (char *)r;
}
> the main issue here is that this is vn_reference vs. vn_nary handling and
> this
> transitions from vn_reference to possibly vn_nary with valueization. For VN
> &MEM[p + 1] was more canonical and we could go back to this when seeing
> pointer-plus -- at least when lookup & simplification does not produce a
> redundancy.
>
> Handling this in VN only and only when inlining is complete might also avoid
> regressing the testcase again.
The adjusted testcase is folded in forwprop after inlining which handles
p+4 == &p->a[1]
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162
--- Comment #4 from Richard Biener ---
Btw, in VN it would be nice to handle
struct S { int i; };
int i;
int bar (char *p)
{
char *q = p + 1;
i = 1;
char *r = (char *)&(((struct S *)&p[i])->i);
return q == r;
}
the main issue here is that this is vn_reference vs. vn_nary handling and this
transitions from vn_reference to possibly vn_nary with valueization. For VN
&MEM[p + 1] was more canonical and we could go back to this when seeing
pointer-plus -- at least when lookup & simplification does not produce a
redundancy.
Handling this in VN only and only when inlining is complete might also avoid
regressing the testcase again.
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 --- Comment #3 from Andrew Pinski --- Right my original version of the lowering handled this. I guess we need to handle the case where we have a handled reference too. But that would regress PR 99673 again. I will take a look this weekend.
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162
--- Comment #2 from Richard Biener ---
Testcase that did not regress:
struct S { int i; };
void foo (int *);
void bar (char *p)
{
foo (&((struct S *)(p + 1))->i);
foo ((int *)(p + 1));
}
Testcase that did regress (use -fgimple):
struct S { int i; };
void foo (int *);
void __GIMPLE (ssa)
bar (char * p)
{
int * D_1997;
int * _2;
char * _3;
__BB(2):
_2 = &__MEM ((struct S *)p_5(D) + _Literal (struct S *) 1).i;
foo (_2);
_3 = &__MEM ((struct S *)p_5(D) + _Literal (struct S *)1);
foo (_3);
return;
}
it regressed because forwprop now rewrites one of the &MEMs:
--- t.c.033t.ccp1 2022-01-21 14:12:01.392883591 +0100
+++ t.c.034t.forwprop1 2022-01-21 14:12:01.392883591 +0100
@@ -10,7 +10,7 @@
:
_2_6 = &MEM[(struct S *)p_5(D) + 1B].i;
foo (_2_6);
- _3_9 = &MEM[(struct S *)p_5(D) + 1B];
+ _3_9 = p_5(D) + 1;
foo (_3_9);
return;
[Bug tree-optimization/104162] [12 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |12.0 Ever confirmed|0 |1 CC||pinskia at gcc dot gnu.org Last reconfirmed||2022-01-21 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- I will have a look.
