Investigate alternatives to ported SparseAnalysis

[iangneal]

In this PR: #307, we removed the ported DenseAnalysis since we no longer needed a custom implementation.

The SparseAnalysis was ported for a similar reason, but also has changes to the (non-virtual) visitOperation function so that operations without results (constraints, member writes, etc) are visited.

llzk-lib/lib/Analysis/SparseAnalysis.cpp

Lines 102 to 105 in 67030b1

	LogicalResult AbstractSparseForwardDataFlowAnalysis::visitOperation(Operation *op) {
	/// LLZK: Visit operations with no results, as they may still affect values
	/// (e.g., constraints and assertions).
	/// The MLIR version doesn't visit result-less operations.

We can likely implement this functionality in a different way tnat allows us to remove this port.

[1sgtpepper]

@iangneal I think a good path here is to replace the ported SparseAnalysis.cpp with a small LLZK compatibility adapter over upstream MLIR sparse forward analysis.

Most of the behavior can stay fully upstream-owned:

• result-producing operation transfer
• block-start handling
• block argument propagation
• call/result propagation
• region successor propagation
• Executable / PredecessorState handling

The one LLZK-specific piece to keep is the current treatment of live zero-result ops. Upstream MLIR 20.1.8 skips those, but LLZK still needs them visited for constraints/assertions and storage writes like struct.writem / array.write.

So the adapter would only preserve:

• liveness check
• operand lattice collection
• useDefSubscribe(this) on operands
• call handling before typed transfer
• typed visitOperation(op, operands, emptyResults) for non-call, non-region-branch zero-result ops

That seems like the narrowest way to remove the copied MLIR implementation while keeping the behavior that motivated the port in the first place.

A few implementation notes:

• keep the existing llzk::dataflow::SparseForwardDataFlowAnalysis<StateT> name for minimal churn
• include mlir/Analysis/DataFlow/DeadCodeAnalysis.h for Executable / PredecessorState
• add an explicit MLIRAnalysis link dependency after deleting lib/Analysis/SparseAnalysis.cpp
• add a focused regression showing a zero-result op is revisited when an operand lattice changes

[iangneal]

@Kuhai9801 This seems like a reasonable strategy, though I won't have time to work on this for a while. If you'd like to give this plan a shot, I'd be more than happy to review a PR or even a draft PR of your progress.

[1sgtpepper]

Made it here: #555

[tim-hoffman]

resolved by #555