[P0] Codegen error for FIR on 2x4 CGRA

[tancheng]

The arch.yaml:

architecture:
  name: Reference CGRA Device
  version: '1.0'
multi_cgra_defaults:
  base_topology: mesh
  rows: 1
  columns: 1
  memory:
    capacity: 1024
per_cgra_defaults:
  rows: 2
  columns: 4
  ctrl_mem_items: 8
  base_topology: mesh
  memory:
    banks: 16
tile_defaults:
  num_registers: 32
  operations:
    - add
    - load
    - logic
    - mac
    - mul
    - phi
    - shift
    - store
link_defaults:
  latency: 1
  bandwidth: 32
link_overrides: []
tile_overrides: []
extensions:
  crossbar: false
simulator:
  execution_model: serial
  logging:
    enabled: true
    file: output.log
  driver:
    name: Driver
    frequency: 1GHz
  device:
    name: Device
    frequency: 1GHz
    bind_to_architecture: true

It reports:

/cgra/dataflow/test/e2e/fir/Output/fir_kernel.mlir.tmp-kernel.mlir:14:17: error: same-tile data_mov without register mapping is illegal. Provide a register in mapping_locs.
  ^bb1(%4: i64, %5: i32):  // 2 preds: ^bb0, ^bb1

Either sth wrong with mapping or with codegen.

@ShangkunLi Can you plz help take a look?

[ShangkunLi]

Hi~ @tancheng @n0thingNoob,

The problem comes from insufficient instructions in each tile. The minimum instruction set for this kernel is:

tile_defaults:
  num_registers: 32
  operations:
    - add
    - load
    - mul
    - phi
    - icmp
    - grant_once
    - not
    - grant_predicate
    - gep
    - return

[tancheng]

hmm, we should somehow have a FU->operations mapping. From HW tile perspective, the FUs are:

    - add
    - logic
    - mac
    - mul
    - div
    - phi
    - shift
    - mem
    - return
    - grant

it corresponds to operations from SW perspective:

    - add
      - add
      - sub
    - logic
      - ^
      - |
      - xor
    - mac
    - mul
    - div
    - phi
    - shift
      - left/right logic shift
      - left/right arith shift
    - mem
      - load
      - store
    - return
    - grant
      - grant_once
      - grant_predicate

@BenkangPeng saw similar issue during yaml -> VectorCGRA.

So @syifan can you provide following for now?

    - add
    - load
    - mul
    - phi
    - icmp
    - grant_once
    - not
    - grant_predicate
    - gep
    - return

And @ShangkunLi can help maintain the map in dataflow compiler, i.e., refactor the operation to fu_types:

dataflow/lib/NeuraDialect/Architecture/Architecture.cpp

Lines 14 to 107 in 19f2a17

	void configureSupportedOperations(CustomizableFunctionUnit *function_unit, const std::string &operation) {
	// Integer arithmetic operations.
	if (operation == "add") {
	function_unit->addSupportedOperation(IAdd);
	} else if (operation == "sub") {
	function_unit->addSupportedOperation(ISub);
	} else if (operation == "mul") {
	function_unit->addSupportedOperation(IMul);
	} else if (operation == "div") {
	function_unit->addSupportedOperation(IDiv);
	} else if (operation == "rem") {
	function_unit->addSupportedOperation(IRem);
	}
	// Floating-point arithmetic operations.
	else if (operation == "fadd") {
	function_unit->addSupportedOperation(FAdd);
	} else if (operation == "fsub") {
	function_unit->addSupportedOperation(FSub);
	} else if (operation == "fmul") {
	function_unit->addSupportedOperation(FMul);
	} else if (operation == "fdiv") {
	function_unit->addSupportedOperation(FDiv);
	}
	// Memory operations.
	else if (operation == "load") {
	function_unit->addSupportedOperation(ILoad);
	} else if (operation == "store") {
	function_unit->addSupportedOperation(IStore);
	} else if (operation == "load_indexed") {
	function_unit->addSupportedOperation(ILoadIndexed);
	} else if (operation == "store_indexed") {
	function_unit->addSupportedOperation(IStoreIndexed);
	} else if (operation == "alloca") {
	function_unit->addSupportedOperation(IAlloca);
	}
	// Logical operations.
	else if (operation == "or") {
	function_unit->addSupportedOperation(IOr);
	} else if (operation == "not") {
	function_unit->addSupportedOperation(INot);
	} else if (operation == "icmp") {
	function_unit->addSupportedOperation(ICmp);
	} else if (operation == "fcmp") {
	function_unit->addSupportedOperation(FCmp);
	} else if (operation == "sel") {
	function_unit->addSupportedOperation(ISel);
	}
	// Type conversion operations.
	else if (operation == "cast") {
	function_unit->addSupportedOperation(ICast);
	} else if (operation == "sext") {
	function_unit->addSupportedOperation(ISExt);
	} else if (operation == "zext") {
	function_unit->addSupportedOperation(IZExt);
	} else if (operation == "shl") {
	function_unit->addSupportedOperation(IShl);
	}
	// Vector and fused operations.
	else if (operation == "vfmul") {
	function_unit->addSupportedOperation(VFMul);
	} else if (operation == "fadd_fadd") {
	function_unit->addSupportedOperation(FAddFAdd);
	} else if (operation == "fmul_fadd") {
	function_unit->addSupportedOperation(FMulFAdd);
	}
	// Control flow operations.
	else if (operation == "return") {
	function_unit->addSupportedOperation(IReturn);
	} else if (operation == "phi") {
	function_unit->addSupportedOperation(IPhi);
	} else if (operation == "loop_control") {
	function_unit->addSupportedOperation(ILoopControl);
	}
	// Data movement operations.
	else if (operation == "data_mov") {
	function_unit->addSupportedOperation(IDataMov);
	} else if (operation == "ctrl_mov") {
	function_unit->addSupportedOperation(ICtrlMov);
	}
	// Predicate and reservation operations.
	else if (operation == "reserve") {
	function_unit->addSupportedOperation(IReserve);
	} else if (operation == "grant_predicate") {
	function_unit->addSupportedOperation(IGrantPredicate);
	} else if (operation == "grant_once") {
	function_unit->addSupportedOperation(IGrantOnce);
	} else if (operation == "grant_always") {
	function_unit->addSupportedOperation(IGrantAlways);
	}
	// Constant operations.
	else if (operation == "constant") {
	function_unit->addSupportedOperation(IConstant);
	}
	}

[ShangkunLi]

And @ShangkunLi can help maintain the map in dataflow compiler, i.e., refactor the operation to fu_types:

Sure~! Will do it soon.

[syifan]

Currently, the frontend simply reports that the command xxx fails. We need to consider a better way to tell the user that such a program cannot execute on the proposed hardware.

Also, some instructions, like return should always be supported and should not be configurable, right?

[tancheng]

Currently, the frontend simply reports that the command xxx fails. We need to consider a better way to tell the user that such a program cannot execute on the proposed hardware.

Also, some instructions, like return should always be supported and should not be configurable, right?

I agree the msg should be more clear about what type failure we are encountering.

And return might be not needed if we are modeling/designing a systolic array, so it is still optional.

@ShangkunLi plz consider reporting the explicit failure reason.

[syifan]

@tancheng @ShangkunLi Could you please check the package below? All benchmarks work except for BICG. Do you know what the problem is? I should have enabled all the functional units I can imagine.

job-package (8).tar.gz

[tancheng]

Thanks @syifan. @ShangkunLi can you plz help check why there is a llvm IR, i.e., %6 = llvm.icmp "sgt" %arg0, %0 : i32 left in the neura IR?

[ShangkunLi]

Thanks @syifan. @ShangkunLi can you plz help check why there is a llvm IR, i.e., %6 = llvm.icmp "sgt" %arg0, %0 : i32 left in the neura IR?

I successfully ran the bicg test kernel through llvm-lit under our latest main branch. I could not reproduce the error...