https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #30 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:f438acf7ce2e6cb862cf62f2543c36639e2af233
commit r14-9997-gf438acf7ce2e6cb862cf62f2543c36639e2af233
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #28 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:85002f8085c25bb3e74ab013581a74e7c7ae006b
commit r14-9969-g85002f8085c25bb3e74ab013581a74e7c7ae006b
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #27 from Richard Biener ---
I think that adjusting an existing upper bound by -1 because of gap peeling
is wrong when that upper bound may not apply to the IV exit. Because gap
peeling only affects the IV exit test and not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #26 from Tamar Christina ---
(In reply to Richard Biener from comment #25)
> That means, when the loop takes the early exit we _must_ take that during
> the vector iterations. Peeling for gaps means if we would take the early
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #24 from Tamar Christina ---
(In reply to Richard Biener from comment #23)
> Maybe easier to understand testcase:
>
> with -O3 -msse4.1 -fno-vect-cost-model we return 20 instead of 8. Adding
> -fdisable-tree-cunroll avoids the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #23 from Richard Biener ---
Maybe easier to understand testcase:
long x[9];
long a[20];
struct { long x; long b[40]; } b;
int __attribute__((noipa))
foo (int n)
{
int i = 0;
int k = 0;
do
{
if (x[k++]) // early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #22 from Tamar Christina ---
note that due to the secondary exit the actual full vector iteration count is 8
scalar elements at VF=4 == 2.
And it's this boundary condition where we fail, since ceil (8/4) == 2. any
other value would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #21 from Tamar Christina ---
Created attachment 57932
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57932=edit
loop.c
attached reduced testcase that reproduces the issue and also checks the buffer
position and copied values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #20 from Tamar Christina ---
This is a bad interaction with early break and peeling for gaps.
when peeling for gaps we set bias_for_lowest to 0, which then negates the ceil
for the upper bound calculation when the div is exact.
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #18 from Richard Biener ---
Just as hint we've had wrong upper bounds on vectorized loops/epilogues which
would trigger wrong unrolling. But then unrolling also always hints as
eventually having wrong range-info.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #17 from Sam James ---
Created attachment 57780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57780=edit
EarlyCSE.cpp.cpp.182t.cunroll-bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #16 from Sam James ---
-fdisable-tree-cunroll seems to help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #15 from Richard Biener ---
The valgrind output might be because we vectorize the loads a[i], a[i+8], ...
as full vector loads at a[i], a[i+8] but the last we access as scalar. So
the uninit load might be harmless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #14 from Richard Biener ---
There are a few vectorizations in the dumps but only one early-exit where
we vectorize
[local count: 102053600]:
first$I_39 = MEM[(struct value_op_iterator *)];
last$I_40 = MEM[(struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #13 from Sam James ---
Created attachment 5
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=5=edit
valgrind output when broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #12 from Sam James ---
Created attachment 57776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57776=edit
EarlyCSE.cpp.cpp.179t.vect-bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #11 from Sam James ---
Created attachment 57775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57775=edit
EarlyCSE.cpp.cpp.178t.ifcvt-bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #10 from Sam James ---
Created attachment 57774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57774=edit
EarlyCSE.cpp.cpp.177t.ch_vect-bad
optimize("O2") on `template
hash_code hash_combine_range_impl(InputIteratorT first,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #9 from Richard Biener ---
Nothing obviously suspicious here ... I wonder if you can attach
177t.ch_vect, 178t.ifcvt and 179t.vect for the case with the single vectorized
bad loop?
Maybe we're running into a latent issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #8 from Sam James ---
Created attachment 57770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57770=edit
EarlyCSE.cpp.cpp.179t.vect.diff
(In reply to Sam James from comment #7)
> I'll go back to trying to see which specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #7 from Sam James ---
I'll go back to trying to see which specific loop it is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #6 from Sam James ---
Modifying llvm/include/llvm/ADT/iterator.h like so helps (!):
```
#pragma GCC push_options
#pragma GCC optimize ("O0")
friend bool operator==(const iterator_adaptor_base ,
const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #5 from Sam James ---
I'm narrowing it down in there, currently several headers deep. I'll finish
that tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #4 from Sam James ---
Created attachment 57752
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57752=edit
EarlyCSE.cpp.ii.xz
The bad object seems to be EarlyCSE.cpp.o. Building it with -O0 makes things
work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Sam James changed:
What|Removed |Added
Summary|[14 regression] LLVM|[14 regression] LLVM
29 matches
Mail list logo
