* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
@ 2024-03-20 10:44 ` sjames at gcc dot gnu.org
2024-03-20 10:53 ` sjames at gcc dot gnu.org
` (30 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-20 10:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Sam James <sjames at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[14 regression] |[14 regression] LLVM
| |miscompiled with -O3
| |-march=znver2
| |-fno-vect-cost-model
--- Comment #1 from Sam James <sjames at gcc dot gnu.org> ---
Bisecting GCC first then I'll bisect object files in LLVM.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
2024-03-20 10:44 ` [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model sjames at gcc dot gnu.org
@ 2024-03-20 10:53 ` sjames at gcc dot gnu.org
2024-03-20 11:49 ` rguenth at gcc dot gnu.org
` (29 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-20 10:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #2 from Sam James <sjames at gcc dot gnu.org> ---
Better output (includes the assertion failure):
```
$ /home/sam/data/build/llvm-project-test/bin/llc -global-isel
-mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o -
/home/sam/git/llvm-project/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
llc: /home/sam/git/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h:243:
llvm::ScopedHashTableScope<K, V, KInfo, AllocatorTy>::~ScopedHashTableScope()
[with K = {anonymous}::CallValue; V = std::pair<llvm::Instruction*, unsigned
int>; KInfo = llvm::DenseMapInfo<{anonymous}::CallValue>; AllocatorTy =
llvm::MallocAllocator]: Assertion `HT.TopLevelMap[ThisEntry->getKey()] ==
ThisEntry && "Scope imbalance!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and
include the crash backtrace.
Stack dump:
0. Program arguments: /home/sam/data/build/llvm-project-test/bin/llc
-global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o
-
/home/sam/git/llvm-project/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
1. Running pass 'Function Pass Manager' on module
'/home/sam/git/llvm-project/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll'.
2. Running pass 'Early CSE' on function '@sample_d_2d'
#0 0x00007f1df2a1709f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/sam/git/llvm-project/llvm/lib/Support/Unix/Signals.inc:602:22
#1 0x00007f1df2a1411b llvm::sys::RunSignalHandlers()
/home/sam/git/llvm-project/llvm/lib/Support/Signals.cpp:104:20
#2 0x00007f1df2a1411b SignalHandler(int)
/home/sam/git/llvm-project/llvm/lib/Support/Unix/Signals.inc:403:31
#3 0x00007f1df226ac10 (/usr/lib64/libc.so.6+0x3bc10)
#4 0x00007f1df22c029c (/usr/lib64/libc.so.6+0x9129c)
#5 0x00007f1df226ab62 raise (/usr/lib64/libc.so.6+0x3bb62)
#6 0x00007f1df22534f0 abort (/usr/lib64/libc.so.6+0x244f0)
#7 0x00007f1df2253418 (/usr/lib64/libc.so.6+0x24418)
#8 0x00007f1df2263392 (/usr/lib64/libc.so.6+0x34392)
#9 0x00007f1df412f794 ~ScopedHashTableScope
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h:243:7
#10 0x00007f1df412f794 ~ScopedHashTableScope
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h:235:1
#11 0x00007f1df412f794 ~NodeScope
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:667:9
#12 0x00007f1df412f794 ~StackNode
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:687:9
#13 0x00007f1df412f794 (anonymous namespace)::EarlyCSE::run()
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:1708:14
#14 0x00007f1df4131085 (anonymous
namespace)::EarlyCSELegacyCommonPass<false>::runOnFunction(llvm::Function&)
/home/sam/git/llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:1782:3
#15 0x00007f1df2ee1291 llvm::FPPassManager::runOnFunction(llvm::Function&)
/home/sam/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1435:40
#16 0x00007f1df2ee179c llvm::ilist_node_base<false>::getNext() const
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ilist_node_base.h:29:45
#17 0x00007f1df2ee179c
llvm::ilist_node_impl<llvm::ilist_detail::node_options<llvm::Function, false,
false, void>>::getNext()
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ilist_node.h:67:66
#18 0x00007f1df2ee179c
llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Function, false,
false, void>, false, false>::operator++()
/home/sam/git/llvm-project/llvm/include/llvm/ADT/ilist_iterator.h:157:25
#19 0x00007f1df2ee179c llvm::FPPassManager::runOnModule(llvm::Module&)
/home/sam/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1480:22
#20 0x00007f1df2ee1f5d runOnModule
/home/sam/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1557:7
#21 0x00007f1df2ee1f5d llvm::legacy::PassManagerImpl::run(llvm::Module&)
/home/sam/git/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:535:55
#22 0x000055c1916feb5b compileModule(char**, llvm::LLVMContext&)
/home/sam/git/llvm-project/llvm/tools/llc/llc.cpp:754:66
#23 0x000055c1916f3753 main
/home/sam/git/llvm-project/llvm/tools/llc/llc.cpp:416:5
#24 0x00007f1df2254e58 (/usr/lib64/libc.so.6+0x25e58)
#25 0x00007f1df2254f15 __libc_start_main (/usr/lib64/libc.so.6+0x25f15)
#26 0x000055c1916f3d01 _start
(/home/sam/data/build/llvm-project-test/bin/llc+0x10d01)
Aborted
```
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
2024-03-20 10:44 ` [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model sjames at gcc dot gnu.org
2024-03-20 10:53 ` sjames at gcc dot gnu.org
@ 2024-03-20 11:49 ` rguenth at gcc dot gnu.org
2024-03-20 17:23 ` [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8 sjames at gcc dot gnu.org
` (28 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-03-20 11:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
Target Milestone|--- |14.0
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (2 preceding siblings ...)
2024-03-20 11:49 ` rguenth at gcc dot gnu.org
@ 2024-03-20 17:23 ` sjames at gcc dot gnu.org
2024-03-20 21:27 ` sjames at gcc dot gnu.org
` (27 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-20 17:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Sam James <sjames at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[14 regression] LLVM |[14 regression] LLVM
|miscompiled with -O3 |miscompiled with -O3
|-march=znver2 |-march=znver2
|-fno-vect-cost-model |-fno-vect-cost-model since
| |r14-6822-g01f4251b8775c8
CC| |tnfchris at gcc dot gnu.org
--- Comment #3 from Sam James <sjames at gcc dot gnu.org> ---
r14-6822-g01f4251b8775c8
so far, isolating it is a pain because sometimes llvm-tblgen will segfault
during the build (it's built-and-then-run to generate machine descriptions).
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (3 preceding siblings ...)
2024-03-20 17:23 ` [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8 sjames at gcc dot gnu.org
@ 2024-03-20 21:27 ` sjames at gcc dot gnu.org
2024-03-21 3:23 ` sjames at gcc dot gnu.org
` (26 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-20 21:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #4 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57752
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57752&action=edit
EarlyCSE.cpp.ii.xz
The bad object seems to be EarlyCSE.cpp.o. Building it with -O0 makes things
work.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (4 preceding siblings ...)
2024-03-20 21:27 ` sjames at gcc dot gnu.org
@ 2024-03-21 3:23 ` sjames at gcc dot gnu.org
2024-03-22 9:47 ` sjames at gcc dot gnu.org
` (25 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-21 3:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #5 from Sam James <sjames at gcc dot gnu.org> ---
I'm narrowing it down in there, currently several headers deep. I'll finish
that tomorrow.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (5 preceding siblings ...)
2024-03-21 3:23 ` sjames at gcc dot gnu.org
@ 2024-03-22 9:47 ` sjames at gcc dot gnu.org
2024-03-22 9:50 ` sjames at gcc dot gnu.org
` (24 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-22 9:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #6 from Sam James <sjames at gcc dot gnu.org> ---
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 &LHS,
const iterator_adaptor_base &RHS) {
return LHS.I == RHS.I;
}
#pragma GCC pop_options
```
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (6 preceding siblings ...)
2024-03-22 9:47 ` sjames at gcc dot gnu.org
@ 2024-03-22 9:50 ` sjames at gcc dot gnu.org
2024-03-22 10:56 ` sjames at gcc dot gnu.org
` (23 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-22 9:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #7 from Sam James <sjames at gcc dot gnu.org> ---
I'll go back to trying to see which specific loop it is.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (7 preceding siblings ...)
2024-03-22 9:50 ` sjames at gcc dot gnu.org
@ 2024-03-22 10:56 ` sjames at gcc dot gnu.org
2024-03-22 11:26 ` rguenth at gcc dot gnu.org
` (22 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-22 10:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #8 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57770&action=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 loop it is.
tamar and richi both suggested separately debug counters.
lbound: 6
ubound: 7
Attached the diff for EarlyCSE.cpp.cpp.179t.vect.
Further suggestions?
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (8 preceding siblings ...)
2024-03-22 10:56 ` sjames at gcc dot gnu.org
@ 2024-03-22 11:26 ` rguenth at gcc dot gnu.org
2024-03-22 12:36 ` law at gcc dot gnu.org
` (21 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-03-22 11:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 downstream? What happens if you
disable most followup passes?
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (9 preceding siblings ...)
2024-03-22 11:26 ` rguenth at gcc dot gnu.org
@ 2024-03-22 12:36 ` law at gcc dot gnu.org
2024-03-22 13:12 ` sjames at gcc dot gnu.org
` (20 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: law at gcc dot gnu.org @ 2024-03-22 12:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
CC| |law at gcc dot gnu.org
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (10 preceding siblings ...)
2024-03-22 12:36 ` law at gcc dot gnu.org
@ 2024-03-22 13:12 ` sjames at gcc dot gnu.org
2024-03-22 13:13 ` sjames at gcc dot gnu.org
` (19 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-22 13:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #10 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57774&action=edit
EarlyCSE.cpp.cpp.177t.ch_vect-bad
optimize("O2") on `template <typename InputIteratorT>
hash_code hash_combine_range_impl(InputIteratorT first, InputIteratorT last)
works,` but O3 is broken.
Unfortunately, novector pragmas don't work on the while()s in there. I get a
ignored warning.
Attached those dumps w/ -fdbg-cnt=vect_loop:7 (so just the one bad loop). I can
tarball up the 6 vs 7 if useful.
Thanks. Will try disabling those passes next..
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (11 preceding siblings ...)
2024-03-22 13:12 ` sjames at gcc dot gnu.org
@ 2024-03-22 13:13 ` sjames at gcc dot gnu.org
2024-03-22 13:13 ` sjames at gcc dot gnu.org
` (18 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-22 13:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #11 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57775&action=edit
EarlyCSE.cpp.cpp.178t.ifcvt-bad
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (12 preceding siblings ...)
2024-03-22 13:13 ` sjames at gcc dot gnu.org
@ 2024-03-22 13:13 ` sjames at gcc dot gnu.org
2024-03-22 13:27 ` sjames at gcc dot gnu.org
` (17 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-22 13:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #12 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57776&action=edit
EarlyCSE.cpp.cpp.179t.vect-bad
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (13 preceding siblings ...)
2024-03-22 13:13 ` sjames at gcc dot gnu.org
@ 2024-03-22 13:27 ` sjames at gcc dot gnu.org
2024-03-22 13:50 ` rguenth at gcc dot gnu.org
` (16 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-22 13:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #13 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57777
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57777&action=edit
valgrind output when broken
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (14 preceding siblings ...)
2024-03-22 13:27 ` sjames at gcc dot gnu.org
@ 2024-03-22 13:50 ` rguenth at gcc dot gnu.org
2024-03-22 13:52 ` rguenth at gcc dot gnu.org
` (15 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-03-22 13:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
There are a few vectorizations in the dumps but only one early-exit where
we vectorize
<bb 2> [local count: 102053600]:
first$I_39 = MEM[(struct value_op_iterator *)&first];
last$I_40 = MEM[(struct value_op_iterator *)&last];
seed_15 = llvm::hashing::detail::get_execution_seed ();
if (first$I_39 != last$I_40)
goto <bb 22>; [94.50%]
<bb 22> [local count: 96440652]:
<bb 3> [local count: 179229733]:
# buffer_ptr_22 = PHI <_20(24), &buffer(22)>
# first$I_24 = PHI <_29(24), first$I_39(22)>
# ivtmp_226 = PHI <ivtmp_216(24), 9(22)>
_20 = buffer_ptr_22 + 8;
ivtmp_216 = ivtmp_226 - 1;
if (ivtmp_216 == 0)
goto <bb 5>; [51.12%]
else
goto <bb 4>; [48.88%]
<bb 4> [local count: 87607493]:
_30 = MEM[(const struct Use *)first$I_24].Val;
_35 = (unsigned long) _30;
MEM <unsigned long> [(char * {ref-all})buffer_ptr_22] = _35;
_29 = first$I_24 + 32;
if (_29 != last$I_40)
goto <bb 24>; [94.50%]
else
goto <bb 5>; [5.50%]
<bb 24> [local count: 82789081]:
goto <bb 3>; [100.00%]
<bb 5> [local count: 96440652]:
# buffer_ptr_248 = PHI <_20(4), buffer_ptr_22(3)>
# first$I_175 = PHI <last$I_40(4), first$I_24(3)>
if (last$I_40 == first$I_175)
...
as far as I can see that's a non-peeled case and from what I see it looks
OK how we process that.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (15 preceding siblings ...)
2024-03-22 13:50 ` rguenth at gcc dot gnu.org
@ 2024-03-22 13:52 ` rguenth at gcc dot gnu.org
2024-03-22 14:27 ` sjames at gcc dot gnu.org
` (14 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-03-22 13:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (16 preceding siblings ...)
2024-03-22 13:52 ` rguenth at gcc dot gnu.org
@ 2024-03-22 14:27 ` sjames at gcc dot gnu.org
2024-03-22 14:37 ` sjames at gcc dot gnu.org
` (13 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-22 14:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #16 from Sam James <sjames at gcc dot gnu.org> ---
-fdisable-tree-cunroll seems to help.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (17 preceding siblings ...)
2024-03-22 14:27 ` sjames at gcc dot gnu.org
@ 2024-03-22 14:37 ` sjames at gcc dot gnu.org
2024-03-26 10:09 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-22 14:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #17 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 57780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57780&action=edit
EarlyCSE.cpp.cpp.182t.cunroll-bad
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (18 preceding siblings ...)
2024-03-22 14:37 ` sjames at gcc dot gnu.org
@ 2024-03-26 10:09 ` rguenth at gcc dot gnu.org
2024-04-02 13:26 ` tnfchris at gcc dot gnu.org
` (11 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-03-26 10:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (19 preceding siblings ...)
2024-03-26 10:09 ` rguenth at gcc dot gnu.org
@ 2024-04-02 13:26 ` tnfchris at gcc dot gnu.org
2024-04-02 16:41 ` tnfchris at gcc dot gnu.org
` (10 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2024-04-02 13:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2024-04-02
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #19 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Thanks! back from holidays and looking into it now.
mine.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (20 preceding siblings ...)
2024-04-02 13:26 ` tnfchris at gcc dot gnu.org
@ 2024-04-02 16:41 ` tnfchris at gcc dot gnu.org
2024-04-11 21:40 ` tnfchris at gcc dot gnu.org
` (9 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2024-04-02 16:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #20 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
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 end up doing on a loop that does:
Analyzing # of iterations of loop 1
exit condition [8, + , 18446744073709551615] != 0
bounds on difference of bases: -8 ... -8
result:
# of iterations 8, bounded by 8
and a VF=4 calculating:
Loop 1 iterates at most 1 times.
Loop 1 likely iterates at most 1 times.
Analyzing # of iterations of loop 1
exit condition [1, + , 1](no_overflow) < bnd.5505_39
bounds on difference of bases: 0 ... 4611686018427387902
Matching expression match.pd:2011, generic-match-8.cc:27
Applying pattern match.pd:2067, generic-match-1.cc:4813
result:
# of iterations bnd.5505_39 + 18446744073709551615, bounded by
4611686018427387902
Estimating sizes for loop 1
...
Induction variable computation will be folded away.
size: 2 if (ivtmp_312 < bnd.5505_39)
Exit condition will be eliminated in last copy.
size: 24-3, last_iteration: 24-5
Loop size: 24
Estimated size after unrolling: 26
;; Guessed iterations of loop 1 is 0.858446. New upper bound 1.
upper bound should be 2 not 1. I have a working patch, trying to create a
standalone testcase for it.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (21 preceding siblings ...)
2024-04-02 16:41 ` tnfchris at gcc dot gnu.org
@ 2024-04-11 21:40 ` tnfchris at gcc dot gnu.org
2024-04-11 21:52 ` tnfchris at gcc dot gnu.org
` (8 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2024-04-11 21:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #21 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Created attachment 57932
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57932&action=edit
loop.c
attached reduced testcase that reproduces the issue and also checks the buffer
position and copied values.
As discussed on IRC when peeling for gaps we need to either adjust the upper
bounds of the vector loop or force the vector loop to get to the scalar loop.
However we already go to the scalar loop, just with the wrong induction value
because we were never supposed to take the main exit.
whether go to the scalar loop depends on
x = (((ptr2 - ptr1) - 16) / 16) + 1
x == (((x - 1) >> 2) << 2)
in this case x == 26, so we do go to the scalar code already, but through the
main exit.
exiting through the main exit assumes you've done all vector iterations, in
this case 6 iterations based on the main exit condition which is first != last.
In this case the inductions values will be set on niters_vector_mult.
so in this case first += 24
But that's wrong since the secondary exit has a known iteration count of 9, due
to (buffer_ptr + store_size) <= buffer_end.
Statement (exit)if (ivtmp_21 != 0)
is executed at most 8 (bounded by 8) + 1 times in loop 1.
So we will always exit through it as 9 < 24.
that means that when we calculate the upper bounds of the vector loop, we must
add a bias so that in this boundary condition that we do an extra partial
vector iteration.
I think the discussion on IRC went off track for a bit and hopefully this
testcase and the explanation above shows that for all early break and all
epilogue peeling reasons, we must bias up for the upper bound to give the
secondary exits a chance to trigger.
So really do think the correct patch is:
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 4375ebdcb49..0973b952c70 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -12144,6 +12144,9 @@ vect_transform_loop (loop_vec_info loop_vinfo, gimple
*loop_vectorized_call)
-min_epilogue_iters to remove iterations that cannot be performed
by the vector code. */
int bias_for_lowest = 1 - min_epilogue_iters;
+ if (LOOP_VINFO_EARLY_BREAKS (loop_vinfo))
+ bias_for_lowest = 1;
+
int bias_for_assumed = bias_for_lowest;
int alignment_npeels = LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo);
if (alignment_npeels && LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo))
for the reasons described above. There's no way for us to take the main exit,
which signifies (we've reached the end of all iterations we can possibly do as
vector) and get the correct induction values in this case.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (22 preceding siblings ...)
2024-04-11 21:40 ` tnfchris at gcc dot gnu.org
@ 2024-04-11 21:52 ` tnfchris at gcc dot gnu.org
2024-04-12 10:12 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2024-04-11 21:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #22 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
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 have done the partial vector iteration.
Basically final_iter_may_be_partial ends up being ignored.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (23 preceding siblings ...)
2024-04-11 21:52 ` tnfchris at gcc dot gnu.org
@ 2024-04-12 10:12 ` rguenth at gcc dot gnu.org
2024-04-12 10:15 ` tnfchris at gcc dot gnu.org
` (6 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-04-12 10:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 exit, loop upper bound is 8 because of this
break;
a[i] = b.b[2*i]; // the misaligned 2*i access causes peeling for gaps
}
while (++i < n);
return i;
}
int main()
{
x[8] = 1;
if (foo (20) != 8)
__builtin_abort ();
return 0;
}
with -O3 -msse4.1 -fno-vect-cost-model we return 20 instead of 8. Adding
-fdisable-tree-cunroll avoids the issue. The upper bound we set on the
vector loop causes us to force taking the IV exit which continues
with i == (niter - 1) / VF * VF, but 'niter' is 20 here.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (24 preceding siblings ...)
2024-04-12 10:12 ` rguenth at gcc dot gnu.org
@ 2024-04-12 10:15 ` tnfchris at gcc dot gnu.org
2024-04-12 10:37 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2024-04-12 10:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #24 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(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 issue. The upper bound we set on the
> vector loop causes us to force taking the IV exit which continues
> with i == (niter - 1) / VF * VF, but 'niter' is 20 here.
yes,indeed, that's what my patch was arguing last time, but I didn't explain it
well enough.
I'm about to send out v2 (waiting for regtest to finish) which hopefully
articulates this better.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (25 preceding siblings ...)
2024-04-12 10:15 ` tnfchris at gcc dot gnu.org
@ 2024-04-12 10:37 ` rguenth at gcc dot gnu.org
2024-04-12 10:40 ` tnfchris at gcc dot gnu.org
` (4 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-04-12 10:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
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
exit during one of the gap peeled iterations this is a conflicting requirement.
Now - the current analysis guarantees that the early exit conditions can
be safely evaluated even for the gap iterations, but not the following
code when the early exit is _not_ taken.
So peeling for gaps and early exit vect are not compatible?
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (26 preceding siblings ...)
2024-04-12 10:37 ` rguenth at gcc dot gnu.org
@ 2024-04-12 10:40 ` tnfchris at gcc dot gnu.org
2024-04-12 11:27 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2024-04-12 10:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #26 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(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
> exit during one of the gap peeled iterations this is a conflicting
> requirement.
> Now - the current analysis guarantees that the early exit conditions can
> be safely evaluated even for the gap iterations, but not the following
> code when the early exit is _not_ taken.
>
> So peeling for gaps and early exit vect are not compatible?
I don't see why not, as my email explains for the early exits we always go
to the scalar loop, which already adheres to the condition of peeling for
gaps.
I just think that peeling for gaps should not force it to exit from the main
exit.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (27 preceding siblings ...)
2024-04-12 10:40 ` tnfchris at gcc dot gnu.org
@ 2024-04-12 11:27 ` rguenth at gcc dot gnu.org
2024-04-15 11:07 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
31 siblings, 0 replies; 33+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-04-12 11:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
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 early exit test.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (28 preceding siblings ...)
2024-04-12 11:27 ` rguenth at gcc dot gnu.org
@ 2024-04-15 11:07 ` cvs-commit at gcc dot gnu.org
2024-04-15 11:08 ` tnfchris at gcc dot gnu.org
2024-04-16 19:56 ` cvs-commit at gcc dot gnu.org
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-04-15 11:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #28 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:
https://gcc.gnu.org/g:85002f8085c25bb3e74ab013581a74e7c7ae006b
commit r14-9969-g85002f8085c25bb3e74ab013581a74e7c7ae006b
Author: Tamar Christina <tamar.christina@arm.com>
Date: Mon Apr 15 12:06:21 2024 +0100
middle-end: adjust loop upper bounds when peeling for gaps and early break
[PR114403].
This fixes a bug with the interaction between peeling for gaps and early
break.
Before I go further, I'll first explain how I understand this to work for
loops
with a single exit.
When peeling for gaps we peel N < VF iterations to scalar.
This happens by removing N iterations from the calculation of niters such
that
vect_iters * VF == niters is always false.
In other words, when we exit the vector loop we always fall to the scalar
loop.
The loop bounds adjustment guarantees this. Because of this we potentially
execute a vector loop iteration less. That is, if you're at the boundary
condition where niters % VF by peeling one or more scalar iterations the
vector
loop executes one less.
This is accounted for by the adjustments in vect_transform_loops. This
adjustment happens differently based on whether the the vector loop can be
partial or not:
Peeling for gaps sets the bias to 0 and then:
when not partial: we take the floor of (scalar_upper_bound / VF) - 1 to
get the
vector latch iteration count.
when loop is partial: For a single exit this means the loop is masked, we
take
the ceil to account for the fact that the loop can
handle
the final partial iteration using masking.
Note that there's no difference between ceil an floor on the boundary
condition.
There is a difference however when you're slightly above it. i.e. if scalar
iterates 14 times and VF = 4 and we peel 1 iteration for gaps.
The partial loop does ((13 + 0) / 4) - 1 == 2 vector iterations. and in
effect
the partial iteration is ignored and it's done as scalar.
This is fine because the niters modification has capped the vector
iteration at
2. So that when we reduce the induction values you end up entering the
scalar
code with ind_var.2 = ind_var.1 + 2 * VF.
Now lets look at early breaks. To make it esier I'll focus on the specific
testcase:
char buffer[64];
__attribute__ ((noipa))
buff_t *copy (buff_t *first, buff_t *last)
{
char *buffer_ptr = buffer;
char *const buffer_end = &buffer[SZ-1];
int store_size = sizeof(first->Val);
while (first != last && (buffer_ptr + store_size) <= buffer_end)
{
const char *value_data = (const char *)(&first->Val);
__builtin_memcpy(buffer_ptr, value_data, store_size);
buffer_ptr += store_size;
++first;
}
if (first == last)
return 0;
return first;
}
Here the first, early exit is on the condition:
(buffer_ptr + store_size) <= buffer_end
and the main exit is on condition:
first != last
This is important, as this bug only manifests itself when the first exit
has a
known constant iteration count that's lower than the latch exit count.
because buffer holds 64 bytes, and VF = 4, unroll = 2, we end up processing
16
bytes per iteration. So the exit has a known bounds of 8 + 1.
The vectorizer correctly analizes this:
Statement (exit)if (ivtmp_21 != 0)
is executed at most 8 (bounded by 8) + 1 times in loop 1.
and as a consequence the IV is bound by 9:
# vect_vec_iv_.14_117 = PHI <_118(9), { 9, 8, 7, 6 }(20)>
...
vect_ivtmp_21.16_124 = vect_vec_iv_.14_117 + { 18446744073709551615,
18446744073709551615, 18446744073709551615, 18446744073709551615 };
mask_patt_22.17_126 = vect_ivtmp_21.16_124 != { 0, 0, 0, 0 };
if (mask_patt_22.17_126 == { -1, -1, -1, -1 })
goto <bb 3>; [88.89%]
else
goto <bb 30>; [11.11%]
The imporant bits are this:
In this example the value of last - first = 416.
the calculated vector iteration count, is:
x = (((ptr2 - ptr1) - 16) / 16) + 1 = 27
the bounds generated, adjusting for gaps:
x == (((x - 1) >> 2) << 2)
which means we'll always fall through to the scalar code. as intended.
Here are two key things to note:
1. In this loop, the early exit will always be the one taken. When it's
taken
we enter the scalar loop with the correct induction value to apply the
gap
peeling.
2. If the main exit is taken, the induction values assumes you've finished
all
vector iterations. i.e. it assumes you have completed 24 iterations, as
we
treat the main exit the same for normal loop vect and early break when
not
PEELED.
This means the induction value is adjusted to ind_var.2 = ind_var.1 + 24
* VF;
So what's going wrong. The vectorizer's codegen is correct and efficient,
however when we adjust the upper bounds, that code knows that the loops
upper
bound is based on the early exit. i.e. 8 latch iterations. or in other
words.
It thinks the loop iterates once.
This is incorrect as the vector loop iterates twice, as it has set up the
induction value such that it exits at the early exit. So it in effect
iterates
2.5x times.
Becuase the upper bound is incorrect, when we unroll it now exits from the
main
exit which uses the incorrect induction value.
So there are three ways to fix this:
1. If we take the position that the main exit should support both
premature
exits and final exits then vect_update_ivs_after_vectorizer needs to be
skipped for this case, and vectorizable_induction updated with third
case
where we reduce with LAST reduction based on the IVs instead of
assuming
you're at the end of the vector loop.
I don't like this approach. It don't think we should add a third
induction
style to cover up an issue introduced by unrolling. It makes the code
harder to follow and makes main exits harder to reason about.
2. We could say that vec_init_loop_exit_info should pick the exit which has
the
smallest known iteration count. This would turn this case into a PEELED
case
and the induction values would be correct as we'd always recalculate
them
from a reduction. This is suboptimal though as the reason we pick the
latch
exit as the IV one is to prevent having to rotate the loop. This
results
in more efficient code for what we assume is the common case, i.e. the
main
exit.
3. In PR113734 we've established that for vectorization of early breaks
that we
must always treat the loop as partial. Here partiallity means that we
have
enough vector elements to start the iteration, but we may take an early
exit
and so never reach the latch/main exit.
This requirement is overwritten by the peeling for gaps adjustment of
the
upper bound. I believe the bug is simply that this shouldn't be done.
The adjustment here is to indicate that the main exit always leads to
the
scalar loop when peeling for gaps.
But this invariant is already always true for all early exits. Remember
that
early exits restart the scalar loop at the start of the vector
iteration, so
the induction values will start it where we want to do the gaps peeling.
I think no# 3 is the correct fix, and also one that doesn't degrade code
quality.
gcc/ChangeLog:
PR tree-optimization/114403
* tree-vect-loop.cc (vect_transform_loop): Adjust upper bounds for
when
peeling for gaps and early break.
gcc/testsuite/ChangeLog:
PR tree-optimization/114403
* gcc.dg/vect/vect-early-break_124-pr114403.c: New test.
* gcc.dg/vect/vect-early-break_125-pr114403.c: New test.
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (29 preceding siblings ...)
2024-04-15 11:07 ` cvs-commit at gcc dot gnu.org
@ 2024-04-15 11:08 ` tnfchris at gcc dot gnu.org
2024-04-16 19:56 ` cvs-commit at gcc dot gnu.org
31 siblings, 0 replies; 33+ messages in thread
From: tnfchris at gcc dot gnu.org @ 2024-04-15 11:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #29 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Fixed, thanks for the report!
^ permalink raw reply [flat|nested] 33+ messages in thread* [Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
2024-03-20 10:44 [Bug tree-optimization/114403] New: [14 regression] sjames at gcc dot gnu.org
` (30 preceding siblings ...)
2024-04-15 11:08 ` tnfchris at gcc dot gnu.org
@ 2024-04-16 19:56 ` cvs-commit at gcc dot gnu.org
31 siblings, 0 replies; 33+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-04-16 19:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #30 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:
https://gcc.gnu.org/g:f438acf7ce2e6cb862cf62f2543c36639e2af233
commit r14-9997-gf438acf7ce2e6cb862cf62f2543c36639e2af233
Author: Tamar Christina <tamar.christina@arm.com>
Date: Tue Apr 16 20:56:26 2024 +0100
testsuite: Fix data check loop on vect-early-break_124-pr114403.c
The testcase had the wrong indices in the buffer check loop.
gcc/testsuite/ChangeLog:
PR tree-optimization/114403
* gcc.dg/vect/vect-early-break_124-pr114403.c: Fix check loop.
^ permalink raw reply [flat|nested] 33+ messages in thread