[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:85333b9265720fc4e49397301cb16324d2b89aa7 commit r13-3126-g85333b9265720fc4e49397301cb16324d2b89aa7 Author: Richard Biener Date: Thu Oct 6 11:20:16 2022 +0200 tree-optimization/107107 - tail-merging VN wrong-code The following fixes an unintended(?) side-effect of the special MODIFY_EXPR expression entries we add for tail-merging during VN. We shouldn't value-number the virtual operand differently here. PR tree-optimization/107107 * tree-ssa-sccvn.cc (visit_reference_op_store): Do not affect value-numbering when doing the tail merging MODIFY_EXPR lookup. * gcc.dg/pr107107.c: New testcase.
[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107
--- Comment #9 from Richard Biener ---
The issue is how we value-number for tail-merging. We do
Processing block 1: BB4
Value numbering stmt = MEM[(long int *)_3] = 2;
RHS 2 simplified to 2
No store match
Value numbering store MEM[(long int *)_3] to 2
Setting value number of .MEM_12 to .MEM_12 (changed)
marking outgoing edge 4 -> 5 executable
Processing block 2: BB3
Value numbering stmt = *_3 = 2;
RHS 2 simplified to 2
Setting value number of .MEM_11 to .MEM_12 (changed)
marking outgoing edge 3 -> 5 executable
Processing block 3: BB5
Value numbering stmt = .MEM_10 = PHI <.MEM_11(3), .MEM_12(4)>
Setting value number of .MEM_10 to .MEM_12 (changed)
Value numbering stmt = _9 = *p_5(D);
Setting value number of _9 to 1 (changed)
oops. So we figure that the two stores from '2' are "redundant" which causes
us to only consider one (the wrong one) when later looking up *p_5(D).
That's
if (!resultsame)
{
/* Only perform the following when being called from PRE
which embeds tail merging. */
if (default_vn_walk_kind == VN_WALK)
{
assign = build2 (MODIFY_EXPR, TREE_TYPE (lhs), lhs, op);
vn_reference_lookup (assign, vuse, VN_NOWALK, , false);
if (vnresult)
{
VN_INFO (vdef)->visited = true;
return set_ssa_val_to (vdef, vnresult->result_vdef);
}
that's a case I never understood fully (and that seems wrong). That
visited flag set is also odd.
I'm testing a patch.
[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener --- I will have a look.
[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107 --- Comment #7 from Rich Felker --- Second one filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115
[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #6 from Alexander Monakov --- (In reply to Andrew Pinski from comment #5) > (In reply to Rich Felker from comment #1) > > There's also a potentially related test case at > > https://godbolt.org/z/jfv1Ge6v4 - I'm not yet clear on whether it's likely > > to have the same root cause. > > This might be a different issue I think. Yeah, that's sched2 reordering the accesses (probably cselib is confused). Needs a separate report.
[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107 --- Comment #5 from Andrew Pinski --- (In reply to Rich Felker from comment #1) > There's also a potentially related test case at > https://godbolt.org/z/jfv1Ge6v4 - I'm not yet clear on whether it's likely > to have the same root cause. This might be a different issue I think.
[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107 Andrew Pinski changed: What|Removed |Added Component|middle-end |tree-optimization Summary|Wrong codegen from TBAA |[10/11/12/13 Regression] |when stores to distinct |Wrong codegen from TBAA |same-mode types are |when stores to distinct |collapsed? |same-mode types are ||collapsed? Status|UNCONFIRMED |NEW Target Milestone|--- |10.5 Last reconfirmed||2022-10-01 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Note this has been to be a regression since tree level PRE is what is causing the issue and that was added in GCC 4 or 4.1.
