[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2024-01-12 Thread tnfchris at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

Tamar Christina  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Tamar Christina  ---
Fixed. Thanks for the report and let me know if there's something still broken.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2024-01-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:e79c5855ab39d96baa7c6bec63eb97715abcf68d

commit r14-7197-ge79c5855ab39d96baa7c6bec63eb97715abcf68d
Author: Tamar Christina 
Date:   Fri Jan 12 15:26:29 2024 +

middle-end: fill in reduction PHI for all alt exits [PR113178]

When we have a loop with more than 2 exits and a reduction I forgot to fill
in
the PHI value for all alternate exits.

All alternate exits use the same PHI value so we should loop over the new
PHI elements and copy the value across since we call the reduction
calculation
code only once for all exits.  This was normally covered up by earlier
parts of
the compiler rejecting loops incorrectly (which has been fixed now).

Note that while I can use the loop in all cases, the reason I separated out
the
main and alt exit is so that if you pass the wrong edge the macro will
assert.

gcc/ChangeLog:

PR tree-optimization/113178
* tree-vect-loop.cc (vect_create_epilog_for_reduction): Fill in all
alternate exits.

gcc/testsuite/ChangeLog:

PR tree-optimization/113178
* gcc.dg/vect/vect-early-break_101-pr113178.c: New test.
* gcc.dg/vect/vect-early-break_102-pr113178.c: New test.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2024-01-12 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:411de96dbf2bdafc7a90ebbfc63e68afd6388d29

commit r14-7195-g411de96dbf2bdafc7a90ebbfc63e68afd6388d29
Author: Tamar Christina 
Date:   Fri Jan 12 15:25:34 2024 +

middle-end: maintain LCSSA form when peeled vector iterations have virtual
operands

This patch fixes several interconnected issues.

1. When picking an exit we wanted to check for niter_desc.may_be_zero not
true.
   i.e. we want to pick an exit which we know will iterate at least once.
   However niter_desc.may_be_zero is not a boolean.  It is a tree that
encodes
   a boolean value.  !niter_desc.may_be_zero is just checking if we have
some
   information, not what the information is.  This leads us to pick a more
   difficult to vectorize exit more often than we should.

2. Because we had this bug, we used to pick an alternative exit much more
ofthen
   which showed one issue, when the loop accesses memory and we "invert it"
we
   would corrupt the VUSE chain.  This is because on an peeled vector
iteration
   every exit restarts the loop (i.e. they're all early) BUT since we may
have
   performed a store, the vUSE would need to be updated.  This version
maintains
   virtual PHIs correctly in these cases.   Note that we can't simply
remove all
   of them and recreate them because we need the PHI nodes still in the
right
   order for if skip_vector.

3. Since we're moving the stores to a safe location I don't think we
actually
   need to analyze whether the store is in range of the memref,  because if
we
   ever get there, we know that the loads must be in range, and if the
loads are
   in range and we get to the store we know the early breaks were not taken
and
   so the scalar loop would have done the VF stores too.

4. Instead of searching for where to move stores to, they should always be
in
   exit belonging to the latch.  We can only ever delay stores and even if
we
   pick a different exit than the latch one as the main one, effects still
   happen in program order when vectorized.  If we don't move the stores to
the
   latch exit but instead to whever we pick as the "main" exit then we can
   perform incorrect memory accesses (luckily these are trapped by
verify_ssa).

5. We only used to analyze loads inside the same BB as an early break, and
also
   we'd never analyze the ones inside the block where we'd be moving memory
   references to.  This is obviously bogus and to fix it this patch splits
apart
   the two constraints.  We first validate that all load memory references
are
   in bounds and only after that do we perform the alias checks for the
writes.
   This makes the code simpler to understand and more trivially correct.

gcc/ChangeLog:

PR tree-optimization/113137
PR tree-optimization/113136
PR tree-optimization/113172
PR tree-optimization/113178
* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
Maintain PHIs on inverted loops.
(vect_do_peeling): Maintain virtual PHIs on inverted loops.
* tree-vect-loop.cc (vec_init_loop_exit_info): Pick exit closes to
latch.
(vect_create_loop_vinfo): Record all conds instead of only alt
ones.

gcc/testsuite/ChangeLog:

PR tree-optimization/113137
PR tree-optimization/113136
PR tree-optimization/113172
PR tree-optimization/113178
* g++.dg/vect/vect-early-break_4-pr113137.cc: New test.
* g++.dg/vect/vect-early-break_5-pr113137.cc: New test.
* gcc.dg/vect/vect-early-break_95-pr113137.c: New test.
* gcc.dg/vect/vect-early-break_96-pr113136.c: New test.
* gcc.dg/vect/vect-early-break_97-pr113172.c: New test.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2024-01-10 Thread jamborm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

Martin Jambor  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #6 from Martin Jambor  ---
(In reply to David Binderman from comment #4)
> Reduced range seems to be g:0994ddd86f9c3d82 to g:a657c7e3518fcfc7.
> 
> All commits in this range are by Tamar.

Specifically r14-6822-g01f4251b8775c8 (Tamar Christina: middle-end: Support
vectorization of loops with multiple exits.)

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2024-01-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2024-01-02 Thread tnfchris at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

Tamar Christina  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=113137
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 CC||tnfchris at gcc dot gnu.org

--- Comment #5 from Tamar Christina  ---
Thanks, fixed by submitted patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2023-12-30 Thread dcb314 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

David Binderman  changed:

   What|Removed |Added

 CC||tamar.christina at arm dot com

--- Comment #4 from David Binderman  ---
Reduced range seems to be g:0994ddd86f9c3d82 to g:a657c7e3518fcfc7.

All commits in this range are by Tamar.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2023-12-30 Thread dcb314 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

--- Comment #3 from David Binderman  ---
After some bisection, range seems to be g:2902300340928989
to g:ed60b2868abdb793, a range of 21 commits.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2023-12-30 Thread dcb314 at hotmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

--- Comment #2 from David Binderman  ---
The bug first seems to occur sometime between git:514ea1df444ca7f6
and git:f19ceb2d49afdfa5, a distance of 83 commits.

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2023-12-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-30

--- Comment #1 from Andrew Pinski  ---
More reduced testcase and converted into one is C code too:
```
struct PixelWeight {
  int m_SrcStart;
  int m_Weights[16];
};
char h;
void f(struct PixelWeight *pPixelWeights) {
int dest_g_m;
long tt;
for (int j = 0; j < 16; j++) {
  int *p = 0;
  if (j < pPixelWeights->m_SrcStart)
p = tt ? >m_Weights[0] : 0;
  int pWeight = *p;
  dest_g_m += pWeight;
}
h = dest_g_m;
}
```

[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use

2023-12-30 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
 Target||x86_64-linux-gnu
   Target Milestone|--- |14.0
Summary|ice in  |[14 Regression] ice in
   |find_uses_to_rename_use |find_uses_to_rename_use
   Keywords||ice-on-valid-code
  Component|c++ |tree-optimization