[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Andrew Pinski --- (In reply to Sergei Trofimovich from comment #8) > I confirm that today's master does not exhibit the failure. Bisecting to the > fix ends up at this fix: > > commit c9b840db504d15db01f06fe1fec38282dbafee07 > Author: Aldy Hernandez > Date: Mon Oct 17 18:56:24 2022 +0200 > > Make sure exported range for SSA post-dominates the DEF in > set_global_ranges_from_unreachable_edges. > > The problem here is that we're exporting a range for an SSA range that > happens on the other side of a __builtin_unreachable, but the SSA does > not post-dominate the definition point. This is causing ivcanon to > unroll things incorrectly. > > This was a snafu when converting the code from evrp. > > PR tree-optimization/107293 > > Looks plausible? Yes because that patch fixes the problem from the patch which you had originally bisect the issue down to. So just closing as a dup of bug 107293. *** This bug has been marked as a duplicate of bug 107293 ***
[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196 --- Comment #8 from Sergei Trofimovich --- I confirm that today's master does not exhibit the failure. Bisecting to the fix ends up at this fix: commit c9b840db504d15db01f06fe1fec38282dbafee07 Author: Aldy Hernandez Date: Mon Oct 17 18:56:24 2022 +0200 Make sure exported range for SSA post-dominates the DEF in set_global_ranges_from_unreachable_edges. The problem here is that we're exporting a range for an SSA range that happens on the other side of a __builtin_unreachable, but the SSA does not post-dominate the definition point. This is causing ivcanon to unroll things incorrectly. This was a snafu when converting the code from evrp. PR tree-optimization/107293 Looks plausible?
[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196 --- Comment #7 from Andrew Pinski --- This might be fixed already.
[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||wrong-code
[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196
--- Comment #6 from Sergei Trofimovich ---
(In reply to Andrew Pinski from comment #4)
> llvm/lib/Target/RISCV/RISCVISelLowering.cpp is huge source and it might have
> undefined code in it.
> Maybe narrow down which function is going wrong.
What would be the best way to do it? I initially tried '#pragma GCC
push_options/#pragma GCC optimize(0)/#pragma GCC pop_options', but the final
result still requires a few headers and RISCVISelLowering.cpp functions to be
outside optimize(0).
I'm afraid I spent on in a few days and filed the bug in hopes there is a nicer
technique to nail down the specific transformation that changes the behaviour.
If there is no better way to do it I'll start sprinkling
__attribute__((noinline, noipa)) around to get broken and working variants
closer.
> Maybe fire up gdb and see where the infinite loop is located too.
Looking at gdb the problem is not very clear: generic (not RISCV-specific code)
at '#8 Run () at llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1538'
implements some instruction selection logic to pick better instructions
(DAGCombiner). Normally it stabilizes, but in this case it does not finish.
Heavy use of STL-like data structures do not make it easier to trace through in
gdb to see where first deviation bet ween good/bad happens. llvm has debugging
mode to dump the transformations applied but enabling it at build time make the
bug to go away.
Full backtrace:
llvm::DenseMapBase,
llvm::detail::DenseMapPair >, llvm::SDNode*,
unsigned int, llvm::DenseMapInfo,
llvm::detail::DenseMapPair
>::LookupBucketFor () at llvm/include/llvm/ADT/DenseMap.h:632
632 if (LLVM_LIKELY(KeyInfoT::isEqual(Val, ThisBucket->getFirst(
{
(gdb) bt
#0 llvm::DenseMapBase,
llvm::detail::DenseMapPair >, llvm::SDNode*,
unsigned int, llvm::DenseMapInfo,
llvm::detail::DenseMapPair
>::LookupBucketFor ()
at llvm/include/llvm/ADT/DenseMap.h:632
#1 llvm::DenseMapBase,
llvm::detail::DenseMapPair >, llvm::SDNode*,
unsigned int, llvm::DenseMapInfo,
llvm::detail::DenseMapPair
>::LookupBucketFor ()
at llvm/include/llvm/ADT/DenseMap.h:663
#2 llvm::DenseMapBase,
llvm::detail::DenseMapPair >, llvm::SDNode*,
unsigned int, llvm::DenseMapInfo,
llvm::detail::DenseMapPair >::try_emplace ()
at llvm/include/llvm/ADT/DenseMap.h:225
#3 llvm::DenseMapBase,
llvm::detail::DenseMapPair >, llvm::SDNode*,
unsigned int, llvm::DenseMapInfo,
llvm::detail::DenseMapPair >::insert ()
at llvm/include/llvm/ADT/DenseMap.h:216
#4 AddToWorklist () at llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:273
#5 0x014f12e8 in AddToWorklist () at
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:268
#6 AddUsersToWorklist () at llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:195
#7 AddToWorklistWithUsers () at
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:200
#8 Run () at llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1538
#9 llvm::SelectionDAG::Combine () at
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:24210
#10 0x015ea7bf in llvm::SelectionDAGISel::CodeGenAndEmitDAG ()
at llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:958
#11 0x015ed2c5 in llvm::SelectionDAGISel::SelectAllBasicBlocks ()
at llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1634
#12 0x015efd8b in llvm::SelectionDAGISel::runOnMachineFunction ()
at llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:515
#13 0x00ba4f34 in llvm::MachineFunctionPass::runOnFunction () at
llvm/lib/CodeGen/MachineFunctionPass.cpp:72
#14 llvm::MachineFunctionPass::runOnFunction () at
llvm/lib/CodeGen/MachineFunctionPass.cpp:37
#15 0x00ff87b0 in llvm::FPPassManager::runOnFunction () at
llvm/lib/IR/LegacyPassManager.cpp:1434
#16 0x00ff8b3c in llvm::FPPassManager::runOnModule () at
llvm/lib/IR/LegacyPassManager.cpp:1480
#17 0x00ffa39e in runOnModule () at
llvm/lib/IR/LegacyPassManager.cpp:1549
#18 llvm::legacy::PassManagerImpl::run () at
llvm/lib/IR/LegacyPassManager.cpp:539
#19 0x0065a38a in compileModule () at llvm/tools/llc/llc.cpp:719
#20 main () at llvm/tools/llc/llc.cpp:417
[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196 --- Comment #5 from Sergei Trofimovich --- (In reply to Andrew Pinski from comment #1) > We definitely needs more information than this. It could very well be a bug > in LLVM too. > Have you tried compiling LLVM with -fsanitize=address ? (In reply to Andrew Pinski from comment #2) > How about -fwrapv ? Tried the following: - -fwrapv: no change, hangup still happens - -fsanitize=address: hangup disappears, no reports on stderr - -fwrapv -fsanitize=address: hangup disappears, no reports on stderr - -fsanitize=undefined: hangup disappears, no reports on stderr
[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196 --- Comment #4 from Andrew Pinski --- llvm/lib/Target/RISCV/RISCVISelLowering.cpp is huge source and it might have undefined code in it. Maybe narrow down which function is going wrong. Maybe fire up gdb and see where the infinite loop is located too.
[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196 --- Comment #3 from Sergei Trofimovich --- The clues: 1. I bisected gcc down to commit 2460f7cdef7ef9c971de79271afc0db73687a272 Author: Aldy Hernandez Date: Fri Sep 23 19:47:33 2022 +0200 Set ranges from unreachable edges for all known ranges. But I suspect it's not the culprit and only a trigger in inliner behaviour change. 2. The bug is probably somewhere in mis-compilation of llvm/lib/Target/RISCV/RISCVISelLowering.cpp. The following workaround repairs the test: --- a/llvm/lib/Target/RISCV/RISCVISelLowering.cpp +++ b/llvm/lib/Target/RISCV/RISCVISelLowering.cpp @@ -1,3 +1,4 @@ +#pragma GCC optimize(0) //===-- RISCVISelLowering.cpp - RISCV DAG Lowering Implementation ===// // // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. $ timeout 10 bin/llc -mtriple=riscv32 -target-abi=ilp32d -mattr=+v,+zfh,+experimental-zvfh,+f,+d -riscv-v-vector-bits-min=128 -riscv-v-fixed-length-vector-lmul-max=1 -verify-machineinstrs ./bug.ll && echo FINISHED || echo TIMED OUT '+experimental-zvfh' is not a recognized feature for this target (ignoring feature) '+experimental-zvfh' is not a recognized feature for this target (ignoring feature) '+experimental-zvfh' is not a recognized feature for this target (ignoring feature) FINISHED 3. It looks like using '-O2 --param=max-inline-insns-single=116' (instead of -O3) against llvm/lib/Target/RISCV/RISCVISelLowering.cpp is enough to trigger the bug. '-O2 --param=max-inline-insns-single=115' sees to work.
[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196 --- Comment #2 from Andrew Pinski --- How about -fwrapv ?
[Bug ipa/107196] [13 Regression] llvm-14.0.6 is miscompiles by gcc-13 in -O3: hangs llvm testsuite (inliner seems to break it)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107196 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-10-09 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- We definitely needs more information than this. It could very well be a bug in LLVM too. Have you tried compiling LLVM with -fsanitize=address ?
