[P0] Problems with e2e conversion

[n0thingNoob]

Summary

Lowering from LLVM/MLIR to the Neura dialect fails on two operations that aren’t currently converted: llvm.fdiv and llvm.fptosi. Additionally, llvm.fdiv receives an operand of type !neura.data<f32, i1>, which triggers a type mismatch.

Failing IR snippet

%13 = llvm.fdiv %12, %3 : f32
%14 = llvm.fptosi %13 : f32 to i32

Error messages

• llvm.fdiv op operand #0 must be floating point LLVM type or LLVM dialect-compatible vector of floating point LLVM type, but got !neura.data<f32, i1>.
• No conversion rule exists for llvm.fptosi.

I have uploaded the histogram to the branch testbench. Here is the PR: #161

[tancheng]

Declare the neura.fdiv by mimicing:

dataflow/include/NeuraDialect/NeuraOps.td

Lines 49 to 61 in 61ea9fe

	def Neura_RemOp : Op<NeuraDialect, "rem">{
	let summary = "Integer remainder operation";
	let description = [{
	Performs an integer remainder operation, computing the result of
	a % b, where % is the remainder operator.
	Example:
	%result = neura.rem %a, %b : i32
	}];
	let arguments = (ins AnyType:$lhs, Optional<AnyType>:$rhs);
	let results = (outs AnyType:$result);
	let traits = [SameOperandsAndResultElementType];
	}

and provide conversion by mimicing:

dataflow/lib/Conversion/LlvmToNeura/LlvmToNeuraPass.cpp

Lines 122 to 135 in 61ea9fe

	struct LlvmSRemToNeuraRem : public OpRewritePattern<LLVM::SRemOp> {
	using OpRewritePattern<LLVM::SRemOp>::OpRewritePattern;
	LogicalResult matchAndRewrite(LLVM::SRemOp op,
	PatternRewriter &rewriter) const override {
	Value lhs = op.getLhs();
	Value rhs = op.getRhs();
	Type resultType = op.getType();
	// Create neura.rem operation to replace llvm.srem
	rewriter.replaceOpWithNewOp<neura::RemOp>(op, resultType, lhs, rhs);
	return success();
	}
	};

Could make it work.

[n0thingNoob]

Declare the neura.fdiv by mimicing:

dataflow/include/NeuraDialect/NeuraOps.td

Lines 49 to 61 in 61ea9fe

def Neura_RemOp : Op<NeuraDialect, "rem">{
let summary = "Integer remainder operation";
let description = [{
Performs an integer remainder operation, computing the result of
a % b, where % is the remainder operator.

 Example: 
   %result = neura.rem %a, %b : i32 

}];
let arguments = (ins AnyType:$lhs, Optional:$rhs);
let results = (outs AnyType:$result);
let traits = [SameOperandsAndResultElementType];
}
and provide conversion by mimicing:

dataflow/lib/Conversion/LlvmToNeura/LlvmToNeuraPass.cpp

Lines 122 to 135 in 61ea9fe

struct LlvmSRemToNeuraRem : public OpRewritePatternLLVM::SRemOp {
using OpRewritePatternLLVM::SRemOp::OpRewritePattern;

LogicalResult matchAndRewrite(LLVM::SRemOp op,
PatternRewriter &rewriter) const override {
Value lhs = op.getLhs();
Value rhs = op.getRhs();
Type resultType = op.getType();

 // Create neura.rem operation to replace llvm.srem 
 rewriter.replaceOpWithNewOp<neura::RemOp>(op, resultType, lhs, rhs); 
 return success(); 

}
};
Could make it work.

Ok, let me try

[n0thingNoob]

I tried this way to solve the two conversion issues:

1. FDiv Conversion (llvm.fdiv → neura.fdiv)
   Problem: The llvm.fdiv operations were not being converted to Neura dialect, causing type mismatch errors.
   Solution:
   Enhanced the operation definition in NeuraOps.td:
   Added proper description and summary
   Fixed arguments from Optional:$rhs to AnyType:$rhs
   Added traits = [SameOperandsAndResultElementType]
   Implemented conversion pattern in LlvmToNeuraPass.cpp:
   struct LlvmFDivToNeuraFDiv : public OpRewritePatternmlir::LLVM::FDivOp {
   LogicalResult matchAndRewrite(mlir::LLVM::FDivOp op, PatternRewriter &rewriter) const override {
   Value lhs = op->getOperand(0);
   Value rhs = op->getOperand(1);
   Type result_type = op->getResult(0).getType();

   if (!mlir::isa(result_type)) return failure();

   rewriter.replaceOpWithNewOpneura::FDivOp(op, result_type, lhs, rhs);
   return success();
   }
   };
   Registered the pattern in runOnOperation() method

2. FPToSI Conversion (llvm.fptosi → neura.cast)
   Problem: The llvm.fptosi operations were not being converted, causing similar type mismatch errors.
   Solution:
   Used existing generic neura.cast operation (no new operation definition needed)
   Implemented conversion pattern in LlvmToNeuraPass.cpp:
   struct LlvmFPToSIToNeuraCast : public OpRewritePatternmlir::LLVM::FPToSIOp {
   LogicalResult matchAndRewrite(mlir::LLVM::FPToSIOp op, PatternRewriter &rewriter) const override {
   Value input = op.getArg();
   Type result_type = op.getType();

   rewriter.replaceOpWithNewOpneura::CastOp(op, result_type, input,
   rewriter.getStringAttr("fptosi"));
   return success();
   }
   };
   Registered the pattern in runOnOperation() method

[tancheng]

So worked or not?

[n0thingNoob]

So worked or not?

Yes, it works and generates the code we want. I will create a PR later to get a review.

[n0thingNoob]

I am working on FFT kernel and have problems with these functions. What are output_dsp and input_dsp here? Where can I find the definition of them?

[tancheng]

Maybe just comment them out. They were to obtain signals as inputs and send outputs to some dsp modules. We might not need them for evaluation.

[n0thingNoob]

ok

[n0thingNoob]

FFT Kernel Compilation Fails at Mapping Stage with -O3

Summary

I got compilation problem when doing FFT kernel compilation with -O3 optimization. It successfully converts all LLVM operations to Neura dialect but fails during the mapping stage with a "same-tile data_mov without register mapping" error.

Environment

• Optimization Level: -O3 -fno-vectorize -fno-unroll-loops
• Kernel: FFT
• Architecture: 4×4 CGRA tiles

Error Message

error: same-tile data_mov without register mapping is illegal. Provide a register in mapping_locs.
mlir-neura-opt: GenerateCodePass.cpp:494: Assertion `false && "same-tile mov without register mapping"' failed.

Steps to Reproduce

1. Prepare FFT kernel (comment out vectorization pragma):

// Line 57 in fft_kernel.c
// #pragma clang loop vectorize(enable) vectorize_width(4) unroll_count(4)

2. Compile with full pipeline:

clang++ -S -emit-llvm -O3 -fno-vectorize -fno-unroll-loops -o kernel.ll fft_kernel.c
llvm-extract --rfunc=".*kernel.*" kernel.ll -o kernel-only.ll
mlir-translate --import-llvm kernel-only.ll -o kernel.mlir
mlir-neura-opt kernel.mlir \
  --assign-accelerator \
  --lower-llvm-to-neura \
  --promote-func-arg-to-const \
  --fold-constant \
  --canonicalize-live-in \
  --leverage-predicated-value \
  --transform-ctrl-to-data-flow \
  --fold-constant \
  --insert-data-mov \
  --map-to-accelerator="mapping-strategy=heuristic" \
  --architecture-spec=architecture.yaml \
  --generate-code -o mapping.mlir

3. Result: Compilation fails at mapping stage

What Fixed

To make -O3 compilation reach the mapping stage, we added 5 missing LLVM-to-Neura conversion rules in LlvmToNeuraPass.cpp:

LLVM Op	Neura Conversion	Implementation
llvm.xor	neura.or	Direct replacement
llvm.and	neura.mul	Boolean AND as multiplication
llvm.fneg	neura.fsub	0.0 - x
llvm.lshr	neura.shl	Right shift as shl(x, -n)
llvm.select	neura.add/mul/sub	cond×true + (1-cond)×false

Result: All LLVM operations now successfully convert to Neura dialect

Current Problem

The mapping heuristic fails to find a valid spatial-temporal schedule for the complex dataflow graph produced by -O3:

Configuration: MAX Backtrack Depth = 3, MAX Candidate Locations = 5
[HeuristicMapping] Starting mapping with 41 operations.
[HeuristicMapping] Filtered 24 non-materialized operations, 17 operations require physical mapping.

The algorithm encounters a same-tile data movement that requires register allocation but cannot find a valid register assignment within the backtracking limits.

Questions

1. Is this a known limitation of the heuristic mapping algorithm with highly optimized code?

2. What are the recommended approaches to handle -O3 optimized kernels?

   • Increase backtracking depth/candidate locations?
   • Use a different mapping strategy?
   • Modify architecture (more registers/tiles)?

3. Should we use lower optimization levels (-O2, -O1) for CGRA compilation, or is there a way to make -O3 work?

Any guidance on tuning the mapping parameters or alternative strategies would be greatly appreciated!

[tancheng]

@ShangkunLi for viz.

@n0thingNoob can you provide the IR before and after ctrl-to-dataflow-pass?

• And I just update the CGRA-Bench to comment out the vectorization: https://github.com/tancheng/CGRA-Bench/blob/e3d163156d1ee4e8a86c11abfe6447dac095a090/kernels/fft/fft.c#L59-L60

[n0thingNoob]

@ShangkunLi for viz.

@n0thingNoob can you provide the IR before and after ctrl-to-dataflow-pass?

• And I just update the CGRA-Bench to comment out the vectorization: https://github.com/tancheng/CGRA-Bench/blob/e3d163156d1ee4e8a86c11abfe6447dac095a090/kernels/fft/fft.c#L59-L60

Sure. Let me update here later.