[CfToHandshake] `hlstool` crashes with unused `memref`

[zhengyao-lin]

Consider these two functions:

func.func @bad(%arg0: memref<1024xi32>, %arg1: memref<1024xi32>) {
    %c1_i32 = arith.constant 1 : i32
    affine.store %c1_i32, %arg1[0] : memref<1024xi32>
    return
}

func.func @good(%arg0: memref<1024xi32>, %arg1: memref<1024xi32>) {
    %c1_i32 = arith.constant 1 : i32
    affine.store %c1_i32, %arg0[0] : memref<1024xi32>
    return
}

On the latest commit of CIRCT, hlstool crashes on the first function with the following assertion error

$ hlstool --ir --output-level=core --dynamic-hw <bad.mlir>

Assertion failed: (use_empty() && "Cannot destroy a value that still has uses!"), function ~IRObjectWithUseList, file UseDefLists.h, line 198.
PLEASE submit a bug report to https://github.com/llvm/circt and include the crash backtrace.
Stack dump:
0.      Program arguments: hlstool bad.mlir --ir --output-level=core --dynamic-hw
 #0 0x0000000100ace810 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (hlstool+0x100072810)
 #1 0x0000000100acc904 llvm::sys::RunSignalHandlers() (hlstool+0x100070904)
 #2 0x0000000100acf2a0 SignalHandler(int, __siginfo*, void*) (hlstool+0x1000732a0)
 #3 0x000000019748f744 (/usr/lib/system/libsystem_platform.dylib+0x1804e3744)
 #4 0x0000000197485888 (/usr/lib/system/libsystem_pthread.dylib+0x1804d9888)
 #5 0x000000019738a850 (/usr/lib/system/libsystem_c.dylib+0x1803de850)
 #6 0x0000000197389a84 (/usr/lib/system/libsystem_c.dylib+0x1803dda84)
 #7 0x0000000101186264 mlir::Block::getTerminator() (.cold.1) (hlstool+0x10072a264)
 #8 0x00000001011858bc mlir::Block::getTerminator() (hlstool+0x1007298bc)
 #9 0x0000000101185784 mlir::Block::eraseArguments(llvm::BitVector const&) (hlstool+0x100729784)
#10 0x00000001017cd1ac mlir::function_interface_impl::eraseFunctionArguments(mlir::FunctionOpInterface, llvm::BitVector const&, mlir::Type) (hlstool+0x100d711ac)
#11 0x0000000100cf0c6c mlir::detail::FunctionOpInterfaceTrait<circt::handshake::FuncOp>::eraseArgument(unsigned int) (hlstool+0x100294c6c)
#12 0x0000000100ceee14 (anonymous namespace)::HandshakeLowerExtmemToHWPass::lowerExtmemToHW(circt::handshake::FuncOp) (hlstool+0x100292e14)
#13 0x0000000100ced184 (anonymous namespace)::HandshakeLowerExtmemToHWPass::runOnOperation() (hlstool+0x100291184)
#14 0x0000000101672240 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (hlstool+0x100c16240)
#15 0x0000000101672d54 mlir::detail::OpToOpPassAdaptor::runPipeline(mlir::OpPassManager&, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int, mlir::PassInstrumentor*, mlir::PassInstrumentation::PipelineParentInfo const*) (hlstool+0x100c16d54)
#16 0x0000000101678584 mlir::PassManager::runPasses(mlir::Operation*, mlir::AnalysisManager) (hlstool+0x100c1c584)
#17 0x0000000101677d1c mlir::PassManager::run(mlir::Operation*) (hlstool+0x100c1bd1c)
#18 0x0000000100a61854 processBuffer(mlir::MLIRContext&, mlir::TimingScope&, llvm::SourceMgr&, std::__1::optional<std::__1::unique_ptr<llvm::ToolOutputFile, std::__1::default_delete<llvm::ToolOutputFile>>>&) (hlstool+0x100005854)
#19 0x0000000100a60848 processInputSplit(mlir::MLIRContext&, mlir::TimingScope&, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer>>, std::__1::optional<std::__1::unique_ptr<llvm::ToolOutputFile, std::__1::default_delete<llvm::ToolOutputFile>>>&) (hlstool+0x100004848)
#20 0x0000000100a5ea0c executeHlstool(mlir::MLIRContext&) (hlstool+0x100002a0c)
#21 0x0000000100a5e128 main (hlstool+0x100002128)
#22 0x00000001970bdd54

The second function @good works fine though.

[thomasnormal]

Rechecked on current workspace build (build_test/bin/hlstool) with the issue reproducer.

Command:

• build_test/bin/hlstool --ir --output-level=core --dynamic-hw /tmp/issue9807.mlir

Current behavior is a verifier error (no crash):

• 'handshake.func' op expected that block argument #0 is used by an 'extmemory' operation

So the original crash mode is no longer reproducible here.

[zhengyao-lin]

Thanks for trying it out!

I updated to the latest commit but I did still get the same assertion error though.
Is it because I'm configuring the CIRCT build differently?

cmake circt/llvm/llvm -B build/circt \
		-DCMAKE_BUILD_TYPE=RelWithDebInfo \
		-DLLVM_ENABLE_ASSERTIONS=ON \
		-DLLVM_TARGETS_TO_BUILD=host \
		-DLLVM_ENABLE_PROJECTS=mlir \
		-DLLVM_EXTERNAL_PROJECTS=circt \
		-DLLVM_EXTERNAL_CIRCT_SOURCE_DIR=circt \
		-DLLVM_ENABLE_LLD=ON \
		-DLLVM_PARALLEL_LINK_JOBS=1

Another more complicated case I hit is this (with the same assertion error)

func.func @bad2(%arg0: memref<1xi32>, %arg1: memref<1xi32>) {
    %c0_i32 = arith.constant 0 : i32
    %0 = affine.load %arg0[0] : memref<1xi32>
    %1 = arith.cmpi ne, %0, %c0_i32 : i32
    scf.if %1 {
        affine.store %c0_i32, %arg0[0] : memref<1xi32>
    } else {
        affine.store %c0_i32, %arg1[0] : memref<1xi32>
    }
    return
}

In this case, both memrefs are used (statically), but the second may not be actually used.

[seldridge]

@thomasnormal, @thomasahle: Due to current CIRCT project policy, we are unable to accept patches from the thomasnormal/circt fork.

For others: please do not upstream any patches from the thomasnormal/circt fork. Additionally, recognize that any comments made by the @thomasnormal account appear to be from one or more AI agents.

For more information, please see this Discourse post: https://discourse.llvm.org/t/circt-project-policy-on-contributions-from-thomasnormal-circt-fork/90075