[Bug tree-optimization/114403] New: [14 regression]

[Bug tree-optimization/114403] New: [14 regression]

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403

            Bug ID: 114403
           Summary: [14 regression]
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57743&action=edit
build-llvm.sh

I get the following test failures for LLVM 17.0.6:
```
********************
Failed Tests (17):
  LLVM :: CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
  LLVM :: CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.d.ll
  LLVM ::
CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.g16.a16.ll
  LLVM :: CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.g16.ll
  LLVM :: CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.image.sample.cd.g16.ll
  LLVM :: CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.image.sample.g16.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.nsa.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.a16.dim.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.cd.a16.dim.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.cd.g16.encode.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.cd.g16.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.dim.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.g16.a16.dim.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.g16.encode.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.g16.ll
  LLVM :: CodeGen/AMDGPU/llvm.amdgcn.image.sample.o.dim.ll
  LLVM :: CodeGen/NVPTX/wmma.py
```

I can reproduce it with -O3 -march=znver -fno-vect-cost-model. It also then
shows up if Clang is used to build Firefox. I will do the usual narrowing down
but my success rate for producing test cases from LLVM is poor ;)

Picking the first one:
```
FAIL: LLVM ::
CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll (5582 of
50819)
******************** TEST 'LLVM ::
CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll' FAILED
********************
Script:
--
: 'RUN: at line 2';  
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc
-global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o
-
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
|
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/FileCheck
-check-prefix=GFX9
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
: 'RUN: at line 3';  
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc
-global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx1010 -stop-after=legalizer -o
-
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
|
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/FileCheck
-check-prefix=GFX10
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
: 'RUN: at line 4';  
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc
-global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx1100 -stop-after=legalizer -o
-
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
|
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/FileCheck
-check-prefix=GFX11
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
--
Exit Code: 2

Command Output (stderr):
--
+ : 'RUN: at line 2'
+
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc
-global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o
-
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
+
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/FileCheck
-check-prefix=GFX9
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and
include the crash backtrace.
Stack dump:
0.      Program arguments:
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc
-global-isel -mtriple=amdgcn-mesa-mesa3d -mcpu=gfx900 -stop-after=legalizer -o
-
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
1.      Running pass 'Function Pass Manager' on module
'/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll'.
2.      Running pass 'Early CSE' on function '@sample_d_3d'
 #0 0x00007f3bd08e5fbf llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/../lib64/libLLVM-17.so+0xee5fbf)
 #1 0x00007f3bd08e315b SignalHandler(int) Signals.cpp:0:0
 #2 0x00007f3bcf46ac10 (/usr/lib64/libc.so.6+0x3bc10)
 #3 0x00007f3bd0a6c5a6 llvm::Instruction::isIdenticalTo(llvm::Instruction
const*) const
(/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/../lib64/libLLVM-17.so+0x106c5a6)
 #4 0x00007f3bd1ed8073 bool llvm::DenseMapBase<llvm::DenseMap<(anonymous
namespace)::CallValue, llvm::ScopedHashTableVal<(anonymous
namespace)::CallValue, std::pair<llvm::Instruction*, unsigned int>>*,
llvm::DenseMapInfo<(anonymous namespace)::CallValue, void>,
llvm::detail::DenseMapPair<(anonymous namespace)::CallValue,
llvm::ScopedHashTableVal<(anonymous namespace)::CallValue,
std::pair<llvm::Instruction*, unsigned int>>*>>, (anonymous
namespace)::CallValue, llvm::ScopedHashTableVal<(anonymous
namespace)::CallValue, std::pair<llvm::Instruction*, unsigned int>>*,
llvm::DenseMapInfo<(anonymous namespace)::CallValue, void>,
llvm::detail::DenseMapPair<(anonymous namespace)::CallValue,
llvm::ScopedHashTableVal<(anonymous namespace)::CallValue,
std::pair<llvm::Instruction*, unsigned int>>*>>::LookupBucketFor<(anonymous
namespace)::CallValue>((anonymous namespace)::CallValue const&,
llvm::detail::DenseMapPair<(anonymous namespace)::CallValue,
llvm::ScopedHashTableVal<(anonymous namespace)::CallValue,
std::pair<llvm::Instruction*, unsigned int>>*> const*&) const EarlyCSE.cpp:0:0
 #5 0x00007f3bd1eddbe7 (anonymous namespace)::EarlyCSE::run() EarlyCSE.cpp:0:0
 #6 0x00007f3bd1ee0da2 (anonymous
namespace)::EarlyCSELegacyCommonPass<false>::runOnFunction(llvm::Function&)
EarlyCSE.cpp:0:0
 #7 0x00007f3bd0aac88e llvm::FPPassManager::runOnFunction(llvm::Function&)
(/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/../lib64/libLLVM-17.so+0x10ac88e)
 #8 0x00007f3bd0aacd9c llvm::FPPassManager::runOnModule(llvm::Module&)
(/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/../lib64/libLLVM-17.so+0x10acd9c)
 #9 0x00007f3bd0aad478 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/../lib64/libLLVM-17.so+0x10ad478)
#10 0x000055ce81b49356 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#11 0x000055ce81b3ead3 main
(/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc+0x11ad3)
#12 0x00007f3bcf454e58 (/usr/lib64/libc.so.6+0x25e58)
#13 0x00007f3bcf454f15 __libc_start_main (/usr/lib64/libc.so.6+0x25f15)
#14 0x000055ce81b3efb1 _start
(/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/llc+0x11fb1)
FileCheck error: '<stdin>' is empty.
FileCheck command line: 
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm_build-abi_x86_64.amd64/bin/FileCheck
-check-prefix=GFX9
/var/tmp/portage/sys-devel/llvm-17.0.6/work/llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
```

Simpler reproducer is then: ~/git/llvm-project $
~/data/build/llvm-project-test/bin/llvm-lit
./llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-llvm.amdgcn.image.sample.a16.ll
-v.

And then: `/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`.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model

[sjames at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model

[sjames at gcc dot gnu.org]

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
```

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model

[rguenth at gcc dot gnu.org]

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

[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]

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).

[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]

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.

[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]

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.

[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]

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
```

[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]

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.

[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]

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?

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[rguenth at gcc dot gnu.org]

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?

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[law at gcc dot gnu.org]

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

[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]

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..

[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]

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

[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]

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

[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]

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

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[rguenth at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[rguenth at gcc dot gnu.org]

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.

[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]

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.

[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]

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

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[rguenth at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[tnfchris at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[tnfchris at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[tnfchris at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[tnfchris at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[rguenth at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[tnfchris at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[rguenth at gcc dot gnu.org]

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?

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[tnfchris at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[rguenth at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[cvs-commit at gcc dot gnu.org]

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.

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[tnfchris at gcc dot gnu.org]

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!

[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8

[cvs-commit at gcc dot gnu.org]

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.