Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LLVM IR computeInstrHeights crash #59751

Closed
Sintendo opened this issue Dec 30, 2022 · 4 comments
Closed

LLVM IR computeInstrHeights crash #59751

Sintendo opened this issue Dec 30, 2022 · 4 comments
Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] llvm:codegen

Comments

@Sintendo
Copy link

Sintendo commented Dec 30, 2022

https://godbolt.org/z/j7a6Mj9bM

The following LLVM IR crashes when compiled on the latest trunk and LLVM versions >= 10.

target triple = "arm64-apple-ios14.0.0"

define void @"func"(i32** swifterror %0) #0 {
  br label %thirtyeight

five:
  br label %UelOc2l.exit

common.ret:
  ret void

UelOc2l.exit:
  %a = getelementptr inbounds [754 x i8*], [754 x i8*]* undef, i32 undef, i32 undef
  %b = load i8*, i8** %a, align 8
  %c = bitcast i8* %b to void ()*
  call void %c()
  br label %common.ret

thirtythree:
  br i1 false, label %UelOc2l.exit, label %thirtythree

thirtyeight:
  br i1 undef, label %thirtyeight, label %thirtythree
}

attributes #0 = { noinline optnone "target-cpu"="apple-a7" }
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/clang-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel <source>
1.	Running pass 'Function Pass Manager' on module '<source>'.
2.	Running pass 'Machine InstCombiner' on function '@func'
 #0 0x00005600140f1edf llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-trunk/bin/llc+0x32e4edf)
 #1 0x00005600140ef954 SignalHandler(int) Signals.cpp:0:0
 #2 0x00007f99fb600420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #3 0x00005600134444bf getDataDeps(llvm::MachineInstr const&, llvm::SmallVectorImpl<(anonymous namespace)::DataDep>&, llvm::MachineRegisterInfo const*) (.part.0) MachineTraceMetrics.cpp:0:0
 #4 0x0000560013446664 llvm::MachineTraceMetrics::Ensemble::computeInstrHeights(llvm::MachineBasicBlock const*) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2639664)
 #5 0x0000560013449ccf llvm::MachineTraceMetrics::Ensemble::getTrace(llvm::MachineBasicBlock const*) (/opt/compiler-explorer/clang-trunk/bin/llc+0x263cccf)
 #6 0x0000560013351db6 (anonymous namespace)::MachineCombiner::combineInstructions(llvm::MachineBasicBlock*) MachineCombiner.cpp:0:0
 #7 0x00005600133532fb (anonymous namespace)::MachineCombiner::runOnMachineFunction(llvm::MachineFunction&) MachineCombiner.cpp:0:0
 #8 0x00005600133900c0 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
 #9 0x0000560013876780 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2a69780)
#10 0x00005600138768f9 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2a698f9)
#11 0x00005600138774e0 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2a6a4e0)
#12 0x000056001180bfc3 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#13 0x000056001174489a main (/opt/compiler-explorer/clang-trunk/bin/llc+0x93789a)
#14 0x00007f99fb0ae083 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24083)
#15 0x0000560011803f0e _start (/opt/compiler-explorer/clang-trunk/bin/llc+0x9f6f0e)
Compiler returned: 139
@EugeneZelenko EugeneZelenko added llvm:optimizations crash Prefer [crash-on-valid] or [crash-on-invalid] and removed new issue labels Dec 30, 2022
@llvmbot
Copy link
Collaborator

llvmbot commented Jan 2, 2023

@llvm/issue-subscribers-backend-aarch64

@rotateright
Copy link
Contributor

This is either a bug in the generic part of MachineCombiner or the AArch-specific overrides. Looks like it repros all the way back to LLVM 10.0 (might exist before that too, but need to adjust IR test) and forward to today's trunk.

@fzhinkin
Copy link
Contributor

fzhinkin commented Jan 5, 2023

The crash happened because SwiftError.getOrCreateVRegUseAt created a new vreg use after it been called from SelectionDAGBuilder::visitRet. After instruction selection SwiftErrorValueTracking::propagateVRegs should connect all such swift-error's uses with defs by iterating over basic blocks in RPO, but the basic block common.ret is no longer reachable after isel and because of that there is no definition for the problematic vreg.

I think it's should be safe to simply insert implicit def for all vregs from VRegUpwardsUse that don't have a definition at the end of propagateVRegs: https://reviews.llvm.org/D141053

fzhinkin added a commit that referenced this issue Aug 20, 2023
SwiftErrorValueTracking creates vregs at swifterror use sites and then
connects it with appropriate definitions after instruction selection.
To propagate swifterror values SwiftErrorValueTracking::propagateVRegs
iterates over basic blocks in RPO, but some vregs previously created
at use sites may be located in blocks that became unreachable after
instruction selection. Because of that there will no definition for
such vregs and that may cause issues down the pipeline.

To ensure that all vregs created by the SwiftErrorValueTracking will
be defined propagateVRegs was updated to insert IMPLICIT_DEF at the
beginning of unreachable blocks containing swifterror uses.

Related issue: #59751

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D141053
@fzhinkin
Copy link
Contributor

Fixed in 08d0b55

razmser pushed a commit to SuduIDE/llvm-project that referenced this issue Oct 2, 2023
SwiftErrorValueTracking creates vregs at swifterror use sites and then
connects it with appropriate definitions after instruction selection.
To propagate swifterror values SwiftErrorValueTracking::propagateVRegs
iterates over basic blocks in RPO, but some vregs previously created
at use sites may be located in blocks that became unreachable after
instruction selection. Because of that there will no definition for
such vregs and that may cause issues down the pipeline.

To ensure that all vregs created by the SwiftErrorValueTracking will
be defined propagateVRegs was updated to insert IMPLICIT_DEF at the
beginning of unreachable blocks containing swifterror uses.

Related issue: llvm#59751

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D141053
razmser pushed a commit to SuduIDE/llvm-project that referenced this issue Oct 2, 2023
SwiftErrorValueTracking creates vregs at swifterror use sites and then
connects it with appropriate definitions after instruction selection.
To propagate swifterror values SwiftErrorValueTracking::propagateVRegs
iterates over basic blocks in RPO, but some vregs previously created
at use sites may be located in blocks that became unreachable after
instruction selection. Because of that there will no definition for
such vregs and that may cause issues down the pipeline.

To ensure that all vregs created by the SwiftErrorValueTracking will
be defined propagateVRegs was updated to insert IMPLICIT_DEF at the
beginning of unreachable blocks containing swifterror uses.

Related issue: llvm#59751

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D141053
razmser pushed a commit to SuduIDE/llvm-project that referenced this issue Oct 2, 2023
SwiftErrorValueTracking creates vregs at swifterror use sites and then
connects it with appropriate definitions after instruction selection.
To propagate swifterror values SwiftErrorValueTracking::propagateVRegs
iterates over basic blocks in RPO, but some vregs previously created
at use sites may be located in blocks that became unreachable after
instruction selection. Because of that there will no definition for
such vregs and that may cause issues down the pipeline.

To ensure that all vregs created by the SwiftErrorValueTracking will
be defined propagateVRegs was updated to insert IMPLICIT_DEF at the
beginning of unreachable blocks containing swifterror uses.

Related issue: llvm#59751

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D141053
razmser pushed a commit to SuduIDE/llvm-project that referenced this issue Oct 3, 2023
SwiftErrorValueTracking creates vregs at swifterror use sites and then
connects it with appropriate definitions after instruction selection.
To propagate swifterror values SwiftErrorValueTracking::propagateVRegs
iterates over basic blocks in RPO, but some vregs previously created
at use sites may be located in blocks that became unreachable after
instruction selection. Because of that there will no definition for
such vregs and that may cause issues down the pipeline.

To ensure that all vregs created by the SwiftErrorValueTracking will
be defined propagateVRegs was updated to insert IMPLICIT_DEF at the
beginning of unreachable blocks containing swifterror uses.

Related issue: llvm#59751

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D141053
razmser pushed a commit to SuduIDE/llvm-project that referenced this issue Oct 3, 2023
SwiftErrorValueTracking creates vregs at swifterror use sites and then
connects it with appropriate definitions after instruction selection.
To propagate swifterror values SwiftErrorValueTracking::propagateVRegs
iterates over basic blocks in RPO, but some vregs previously created
at use sites may be located in blocks that became unreachable after
instruction selection. Because of that there will no definition for
such vregs and that may cause issues down the pipeline.

To ensure that all vregs created by the SwiftErrorValueTracking will
be defined propagateVRegs was updated to insert IMPLICIT_DEF at the
beginning of unreachable blocks containing swifterror uses.

Related issue: llvm#59751

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D141053
razmser pushed a commit to SuduIDE/llvm-project that referenced this issue Oct 6, 2023
SwiftErrorValueTracking creates vregs at swifterror use sites and then
connects it with appropriate definitions after instruction selection.
To propagate swifterror values SwiftErrorValueTracking::propagateVRegs
iterates over basic blocks in RPO, but some vregs previously created
at use sites may be located in blocks that became unreachable after
instruction selection. Because of that there will no definition for
such vregs and that may cause issues down the pipeline.

To ensure that all vregs created by the SwiftErrorValueTracking will
be defined propagateVRegs was updated to insert IMPLICIT_DEF at the
beginning of unreachable blocks containing swifterror uses.

Related issue: llvm#59751

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D141053
razmser pushed a commit to SuduIDE/llvm-project that referenced this issue Oct 11, 2023
SwiftErrorValueTracking creates vregs at swifterror use sites and then
connects it with appropriate definitions after instruction selection.
To propagate swifterror values SwiftErrorValueTracking::propagateVRegs
iterates over basic blocks in RPO, but some vregs previously created
at use sites may be located in blocks that became unreachable after
instruction selection. Because of that there will no definition for
such vregs and that may cause issues down the pipeline.

To ensure that all vregs created by the SwiftErrorValueTracking will
be defined propagateVRegs was updated to insert IMPLICIT_DEF at the
beginning of unreachable blocks containing swifterror uses.

Related issue: llvm#59751

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D141053
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crash Prefer [crash-on-valid] or [crash-on-invalid] llvm:codegen
Projects
None yet
Development

No branches or pull requests

5 participants