https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121382
Tamar Christina changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Commen
|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
--- Comment #6 from Tamar Christina ---
Looks like because it thinks that
f = f - e;
if (c - 9 * f) {
__builtin_abort();
is always true, but misses the obvious case that when c == 0 and e ==
2147483647 c will be 0 and stay 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121382
--- Comment #5 from Tamar Christina ---
Ok, taking a look at c0 and C2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121383
--- Comment #3 from Tamar Christina ---
(In reply to Richard Biener from comment #2)
> if-conversion does nothing to loops with multiple exits. One could think to
> sub-divide its work, but in this case there's a lack of PHIs and the
> expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120996
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
: normal
Priority: P3
Component: tree-optimization
Assignee: tnfchris at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947, 115130
Target Milestone: ---
The following example loop:
#define N 1000
int a[N] = {0};
int b[N] = {0};
int c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115130
Bug 115130 depends on bug 54013, which changed state.
Bug 54013 Summary: Loop with control flow not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54013
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 54013, which changed state.
Bug 54013 Summary: Loop with control flow not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54013
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54013
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 121190, which changed state.
Bug 121190 Summary: [15 regression] Segmentation fault when executing
vectorized loops with -O3 -march=znver2 since r15-6807-g68326d5d1a593d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121190
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121190
--- Comment #7 from Tamar Christina ---
Backported to GCC 15 to make RC1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121190
Tamar Christina changed:
What|Removed |Added
Summary|[15/16 regression] |[15 regression]
|Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577
Tamar Christina changed:
What|Removed |Added
Blocks||53947, 115130
--- Comment #5 from Tam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #19 from Tamar Christina ---
(In reply to Avinash Jayakar from comment #18)
> (In reply to Tamar Christina from comment #17)
> > (In reply to Avinash Jayakar from comment #16)
> > > Created attachment 61956 [details]
> > > I have jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121240
--- Comment #2 from Tamar Christina ---
(In reply to Andrew Pinski from comment #1)
> Can't use section anchors due to merging at link time.
We can, you just have to make them a subsection, then you control the
unit of merging.
-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Couldn't find an existing ticket for this. but the following example
const dou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #17 from Tamar Christina ---
(In reply to Avinash Jayakar from comment #16)
> Created attachment 61956 [details]
> I have just changed the order within the conditional where the const_vf gets
> assigned, to have it behave in similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #13 from Tamar Christina ---
(In reply to Avinash Jayakar from comment #11)
>
> > I think the code before worked because a non-partial epilogue would have
> > niters_vector
> > be a const (e.g. a gimple value) but the partial iterati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #9 from Tamar Christina ---
(In reply to Avinash Jayakar from comment #8)
> (In reply to Tamar Christina from comment #7)
> > (In reply to Avinash Jayakar from comment #6)
> > No, const_vf will be 0 when vector length agnostic code i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #7 from Tamar Christina ---
(In reply to Avinash Jayakar from comment #6)
> (In reply to Tamar Christina from comment #5)
> > (In reply to Avinash Jayakar from comment #4)
> > > So my main doubt here is const_vf, is supposed to be 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #5 from Tamar Christina ---
(In reply to Avinash Jayakar from comment #4)
> So my main doubt here is const_vf, is supposed to be 0 for the epilogue
> block right, just like log_vf was null for the epilogue. If so, this is a
> simple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
--- Comment #9 from Tamar Christina ---
(In reply to Robin Dapp from comment #6)
> (In reply to Tamar Christina from comment #5)
> > Question, can I count on
> >
> > -march=rv64gcv_zvl1024b -mrvv-vector-bits=zvl -mrvv-max-lmul=m8
> >
> > alway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #10 from Tamar Christina ---
Could we perhaps emit additional annotation into gimple to describe what the
vectorizer thinks is safe? And the tool verifies the claims?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
--- Comment #5 from Tamar Christina ---
Question, can I count on
-march=rv64gcv_zvl1024b -mrvv-vector-bits=zvl -mrvv-max-lmul=m8
always being available as a codegen option for RVV? or do I need some
require-effective-target checks?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #5 from Tamar Christina ---
(In reply to Richard Biener from comment #4)
>
> Now, the testcase shows a missed optimization - we are unnecessarily
> using a large VF because of
>
> t.c:2:21: note: ==> examining phi: ivtmp_21 = PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #17 from Tamar Christina ---
(In reply to Richard Biener from comment #16)
> No, that cannot be required for correct operation. I think DSE is wrong in
> assessing that the store covers more than 5 bytes. The following fixes it
> f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #15 from Tamar Christina ---
(In reply to Richard Biener from comment #13)
> (In reply to Tamar Christina from comment #12)
> > Looks like the problem is that during ao_ref_init_from_ptr_and_range when
> > initializing vectp_target.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #1 from Tamar Christina ---
I'm not sure that I'd draw the same conclusion. I view it as the vectorizer has
put a 32-byte alignment requirement on the object and so I'd consider the
object itself to be 32-bytes sized.
So to the not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #12 from Tamar Christina ---
Looks like the problem is that during ao_ref_init_from_ptr_and_range when
initializing vectp_target.14_54 = &targetD.4595 + _55;
we don't enter the block splitting apart POINTER_PLUS_EXPR.
So it ends up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #11 from Tamar Christina ---
(In reply to Richard Biener from comment #10)
> (In reply to Tamar Christina from comment #8)
> > C testcase
> >
> > typedef struct {
> > int _M_current;
> > } __normal_iterator;
> >
> > typedef str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
--- Comment #3 from Tamar Christina ---
before the bounds variable didn't have any range attached to it.
e.g.
bnd.704_180 = _181 - _132;
but now it shows
# RANGE [irange] unsigned int [1, 2147483647]
bnd.704_180 = _181 - _132;
For some reas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120959
Tamar Christina changed:
What|Removed |Added
Assignee|tnfchris at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120959
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #9 from Tamar Christina ---
So the key to triggering it here is the pass by value.
Testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
Tamar Christina changed:
What|Removed |Added
Target|aarch64-linux-gnu |aarch64-*
Build|x86_64-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #7 from Tamar Christina ---
(In reply to Richard Biener from comment #6)
> A C testcase would be really nice.
Have not been able to reproduce it as C yet, but here's a cut-down C++ version
#include
#include
#include
extern int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #4 from Tamar Christina ---
Confirmed, bisecting and taking a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120805
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115842
--- Comment #12 from Tamar Christina ---
(In reply to Hongtao Liu from comment #11)
> (In reply to Tamar Christina from comment #9)
> > (In reply to Hongtao Liu from comment #8)
> > > (In reply to Tamar Christina from comment #7)
> > > > (In rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #10 from Tamar Christina ---
(In reply to ktkachov from comment #9)
> (In reply to Tamar Christina from comment #8)
> > (In reply to ktkachov from comment #7)
> > > Could this be extended to scale Neon intrinsics code to SVE by
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 116855, which changed state.
Bug 116855 Summary: [14 Regression] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
Tamar Christina changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860
Tamar Christina changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
--- Comment #5 from Tamar Christina ---
I could be mistaken, but VNx4QI is a partial vector, so every QI element
occupies 32-bits (so we'd use a widening load here).
I'm not sure this operation is valid for partial vectors as it means you're
ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357
--- Comment #9 from Tamar Christina ---
(In reply to Richard Biener from comment #8)
> The following fixes this. I'm not 100% convinced but it does seem "obvious"
> (but for the "peeled" case we seem to eventually create duplicate COND
> reduct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120447
Tamar Christina changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|needs-source
Status: UNCONFIRMED
Keywords: aarch64-sve, ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
CC: jschmitz at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120383
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> Sure, I'm OK with an optab for it. So it's like (half-type)((unsigned)(a +
> b) >> (sizeof(a)*4))?
Yeah, and I was planning on if an optab was acceptable to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357
--- Comment #7 from Tamar Christina ---
(In reply to Richard Biener from comment #5)
> Confirmed on trunk. I'll eventually have a look.
Sorry I'm on holiday till Tuesday, I'm happy to take a look then if you prefer.
I did not mean to dump my b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120383
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947, 115130
Target Milestone: ---
Target: aarch64*
Today if we unroll an early break loop such as:
#define N 640
long
: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947, 115130
Target Milestone: ---
The following sequence
#define N 4
int a[N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #14 from Tamar Christina ---
(In reply to Richard Biener from comment #13)
> Too late for backporting to 14.3 IMO, also not sure how important it is - we
> did not have an actual case where this caused problems AFAIK. early-break
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #9 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #8)
> On Thu, 8 May 2025, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
> >
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #7 from Tamar Christina ---
(In reply to Richard Biener from comment #6)
> (In reply to Tamar Christina from comment #5)
> > The given example is an easy one to drop, but I wonder what would happen if
> > the block had other instruct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #5 from Tamar Christina ---
(In reply to Richard Biener from comment #4)
> Note with "vectorizing" prefetches I meant adjusting the prefetched address,
> "vectorizing" it as an induction but only prefetching on the first (or
> last?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #3 from Tamar Christina ---
(In reply to Tamar Christina from comment #2)
> (In reply to Richard Biener from comment #1)
> > As of today this is a job for the vectorizer if-conversion pass then.
> >
> > OTOH I believe we should work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> As of today this is a job for the vectorizer if-conversion pass then.
>
> OTOH I believe we should work towards vectorizing the prefetches themselves
> rathe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120157
--- Comment #5 from Tamar Christina ---
(In reply to ktkachov from comment #4)
> > Ah indeed, -msve-vector-bits= does do what I expected. Feel free to close
> > this if it's not tracking anything new then.
>
> Ok. FWIW the original testcase for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120157
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120157
--- Comment #1 from Tamar Christina ---
(In reply to ktkachov from comment #0)
> Not sure if this is a target-specific issue or not. For input:
> int f11(float *x, float val, int n)
> {
> int i;
> for (i = 0; i < n; i++) {
> if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140
--- Comment #20 from Tamar Christina ---
We're currently working on it.
The improvements come from architectures where the code vectorized. The
performance losses come from those where it didn't vectorize, or the vectorizer
generated inefficien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118892
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119921
Tamar Christina changed:
What|Removed |Added
Version|13.3.1 |16.0
Target Milestone|---
-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
Created attachment 61193
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119881
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> I wonder where this matters in practice and my usual stance is educating
> users
> about __restrict or #pragma GCC ivdep or OMP simd safelen is better than
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119872
--- Comment #10 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #9)
> On Mon, 21 Apr 2025, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119872
> >
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119872
--- Comment #8 from Tamar Christina ---
(In reply to Richard Biener from comment #7)
> Please make sure to not "fix" something where the input is already wrong -
> see the various issues where SCEV produces an invalid CHREC - forming a chrec
> i
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
Last reconfirmed||2025-04-21
--- Comment #6 from Tamar Christina ---
Thanks for the report.
This is happening because we're using the affine tree at the
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947, 115130
Target Milestone: ---
Consider the following example:
void foo (int *a1,
int *a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114932
--- Comment #27 from Tamar Christina ---
(In reply to Tianyang Chou from comment #26)
> (In reply to Tamar Christina from comment #0)
>
> Hi Tamar,
> After reading the whole discussion, I still confused about how does the
> immediate offset
-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947, 115130
Target Milestone: ---
consider the following loop:
#define N 512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119286
--- Comment #9 from Tamar Christina ---
(In reply to Thomas Schwinge from comment #8)
> Tamar, thanks! I confirm all fixed -- but one:
>
> (In reply to myself from comment #1)
> > ..., and similarly -- but not identical! -- for '-march=gfx1100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119858
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
Tamar Christina changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #23 from Tamar Christi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
Tamar Christina changed:
What|Removed |Added
Target Milestone|15.0|14.3
Summary|[15 Regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119286
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
Tamar Christina changed:
What|Removed |Added
Keywords|needs-reduction,|
|needs-source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #18 from Tamar Christina ---
(In reply to Richard Biener from comment #17)
> I wonder if we can use
>
> BIT_FIELD_REF
>
> as the "reduction" step.
Yeah that's the same comment Richard S suggested when we were talking to avoid
th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #16 from Tamar Christina ---
Ok, found the bug and c-vise is running for a testcase.
The issue is as follows:
For early break we need to know which value to start the scalar loop with if we
take an early exit.
Historically this me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #15 from Tamar Christina ---
The following example reproduces the CFG but not the bad codegen:
https://godbolt.org/z/Thzo7hz8P
This generates the actual code I expected:
_55 = {_2, _2, _2, _2};
_56 = {_11, _11, _11, _11};
_57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #14 from Tamar Christina ---
There seems to be an one error in the pre-header when calculating the initial
vector IV.
The starting values are calculated as:
sub z27.s, z23.s, z31.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #8 from Tamar Christina ---
(In reply to ktkachov from comment #7)
> Could this be extended to scale Neon intrinsics code to SVE by
> re-vectorising and treating the 128-bit Neon lane as a Q-word element of a
> wider SVE vector? I t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577
--- Comment #2 from Tamar Christina ---
(In reply to Richard Biener from comment #1)
> IIRC it depends on the "kind" of early break whether we need the
> first IV (scalar IV possible) or the last, but I don't rememeber exactly.
First is always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #13 from Tamar Christina ---
Sorry had a week off, looking into this again today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118892
--- Comment #18 from Tamar Christina ---
(In reply to Pavol Rusnak from comment #17)
> Is the fix going to be backported from master to 14.x release? Possibly
> targeting 14.3.0 release?
Yep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #9 from Tamar Christina ---
---
static bool next_ci(int dimYY, int numCells, int nth, int ci_block, int* ci_x,
int* ci_y, int* ci_b, int* ci)
{
while (*ci >= *ci_x * dimYY + *ci_y + 1)
{
*ci_y += 1;
if (*ci_y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115450
--- Comment #11 from Tamar Christina ---
(In reply to Richard Biener from comment #10)
> Can anybody still reproduce this?
I can't. I can reproduce the failure with the original commit but cannot with
today's trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #8 from Tamar Christina ---
Looking at it some more, I think the loop is valid to vectorize. But we don't
seem to vectorize the reduction jumping back to the outerloop:
;; basic block 384, loop depth 3, count 8598980 (estimated lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119402
--- Comment #3 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #2)
> Started with r14-5673-g33c2b70dbabc02788caabcbc66b7baeafeb95bcf
> With -O2 -mtune=generic it is fine even on the current trunk.
Seems like it's due to missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119108
--- Comment #12 from Tamar Christina ---
Sorry for the slow response, had a few days off.
The regression here can be reproduced through this example loop:
https://godbolt.org/z/jnGe5x4P7
for the current loop in snappy what you want is -UALIGNE
1 - 100 of 1328 matches
Mail list logo
