[P0] Add a lowering pattern from `llvm.mlir.addressof` to neura ops

[ShangkunLi]

As @n0thingNoob described, there might be some global address pointer operations when lowering llvm dialect to neura dialect.

For example,

llvm.mlir.global external hidden unnamed_addr @run_gemv_relu_gemv.y() {addr_space = 0 : i32, alignment = 16 : i64, dso_local} : !llvm.array<4 x i32>
llvm.mlir.global external hidden unnamed_addr @run_gemv_relu_gemv.z() {addr_space = 0 : i32, alignment = 16 : i64, dso_local} : !llvm.array<4 x i32>
func.func @kernel_gemv_relu_gemv() -> (i32 {llvm.range = #llvm.constant_range<i32, 0, 256>}) attributes {CConv = #llvm.cconv<ccc>, accelerator = "neura", linkage = #llvm.linkage<external>, memory_effects = #llvm.memory_effects<other = readwrite, argMem = none, inaccessibleMem = none>, no_unwind, passthrough = ["nofree", "norecurse", "nosync", ["uwtable", "2"], ["min-legal-vector-width", "0"], ["no-trapping-math", "true"], ["stack-protector-buffer-size", "8"], ["target-cpu", "x86-64"]], target_cpu = "x86-64", target_features = #llvm.target_features<["+cmov", "+cx8", "+fxsr", "+mmx", "+sse", "+sse2", "+x87"]>, tune_cpu = "generic", unnamed_addr = 1 : i64, visibility_ = 0 : i64} {
    %0 = llvm.mlir.addressof @run_gemv_relu_gemv.z : !llvm.ptr
    %1 = llvm.mlir.addressof @run_gemv_relu_gemv.y : !llvm.ptr
    %2 = "neura.constant"() <{value = 0 : i8}> : () -> i8
    %3 = "neura.constant"() <{value = 16 : i64}> : () -> i64
    %4 = "neura.constant"() <{value = 0 : i64}> : () -> i64
    %5 = "neura.constant"() <{value = 0 : i32}> : () -> i32
    %6 = "neura.constant"() <{value = 1 : i64}> : () -> i64
    %7 = "neura.constant"() <{value = 4 : i64}> : () -> i64
    %8 = "neura.constant"() <{value = 255 : i32}> : () -> i32
    "neura.memset"(%1, %2, %3) <{is_volatile = false}> : (!llvm.ptr, i8, i64) -> ()
    neura.br %4 : i64 to ^bb1
    .....
    .....

We need to add a lowering pattern from llvm.mlir.addressof to neura dialect.

My initial plan is to lower such ops into neura.constant with specific attributes added.

[tancheng]

How would you determine the value of the constant for addr?

Should we have a memory allocation pass to perform simple memory allocation?

[ShangkunLi]

How would you determine the value of the constant for addr?

The llvm.mlir.addressof represents the pointer of a global value. So we can embed the name of the global value into the attribute of the neura.constant to determine the value.

For example,

llvm.mlir.global external hidden unnamed_addr @run_gemv_relu_gemv.y() {addr_space = 0 : i32, alignment = 16 : i64, dso_local} : !llvm.array<4 x i32>

// Source llvm dialect
%0 = llvm.mlir.addressof @run_gemv_relu_gemv.y : !llvm.ptr

// Transformed neura dialect
%0 = "neura.constant"() <{value = @run_gemv_relu_gemv.y}> : () -> !llvm.ptr

Should we have a memory allocation pass to perform simple memory allocation?

Since we do not model the memory architecture in the compiler, we still need a lot of work for that, I think.

[tancheng]

The first PR could be value = @run_gemv_relu_gemv.y, I am fine with it. However, this won't help simulator or RTL, it needs some manual effort to align the address.

The second PR should perform simple address allocation, i.e., @run_gemv_relu_gemv.x = 0, @run_gemv_relu_gemv.y = 4. "we do not model the memory architecture in the compiler" can also be interpreted as "we assume unlimited memory space". I don't think it would be hard as long as each array has fixed size. For the complicated case, we can support them later.

[ShangkunLi]

The second PR should perform simple address allocation, i.e., @run_gemv_relu_gemv.x = 0, @run_gemv_relu_gemv.y = 4. "we do not model the memory architecture in the compiler" can also be interpreted as "we assume unlimited memory space". I don't think it would be hard as long as each array has fixed size. For the complicated case, we can support them later.

Sure~ I have created an issue for this in #290.