main-func-name is not recognized for --convert-to-sdfg

[iBug]

In an attempt to work around #29, I tried separating I/O code (i.e. main()) and computation code (arbitrary non-main function). However I could not find a way for sdfg-opt to run over a non-main function.

Steps

I started with this example.c:

#include <stdlib.h>

int example() {
    int *A = (int *)malloc(100000 * sizeof(int));
    int *B = (int *)malloc(100000 * sizeof(int));
    for (int i = 0; i < 100000; ++i) {
        A[i] = 5;
        for (int j = 0; j < 100000; ++j)
            B[j] = A[i];
        for (int j = 0; j < 10000; ++j)
            A[j] = A[i];
    }
    int res = B[0];
    free(A);
    free(B);
    return res;
}

I compile this C into MLIR with Polygeist:

cgeist -I/usr/lib/llvm-14/lib/clang/14.0.0/include/ -S --function=example -o main.s main.c

The resulting main.s has the following content:

module attributes {dlti.dl_spec = #dlti.dl_spec<#dlti.dl_entry<"dlti.endianness", "little">, #dlti.dl_entry<i64, dense<64> : vector<2xi32>>, #dlti.dl_entry<f80, dense<128> : vector<2xi32>>, #dlti.dl_entry<i1, dense<8> : vector<2xi32>>, #dlti.dl_entry<i8, dense<8> : vector<2xi32>>, #dlti.dl_entry<i16, dense<16> : vector<2xi32>>, #dlti.dl_entry<i32, dense<32> : vector<2xi32>>, #dlti.dl_entry<f16, dense<16> : vector<2xi32>>, #dlti.dl_entry<f64, dense<64> : vector<2xi32>>, #dlti.dl_entry<f128, dense<128> : vector<2xi32>>>, llvm.data_layout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", llvm.target_triple = "x86_64-unknown-linux-gnu", "polygeist.target-cpu" = "x86-64", "polygeist.target-features" = "+cx8,+fxsr,+mmx,+sse,+sse2,+x87", "polygeist.tune-cpu" = "generic"} {
  func.func @example() -> i32 attributes {llvm.linkage = #llvm.linkage<external>} {
    %c10000 = arith.constant 10000 : index
    %c100000 = arith.constant 100000 : index
    %c0 = arith.constant 0 : index
    %c1 = arith.constant 1 : index
    %c5_i32 = arith.constant 5 : i32
    %alloc = memref.alloc() : memref<100000xi32>
    scf.for %arg0 = %c0 to %c100000 step %c1 {
      memref.store %c5_i32, %alloc[%arg0] : memref<100000xi32>
      scf.for %arg1 = %c0 to %c10000 step %c1 {
        %0 = memref.load %alloc[%arg0] : memref<100000xi32>
        memref.store %0, %alloc[%arg1] : memref<100000xi32>
      }
    }
    memref.dealloc %alloc : memref<100000xi32>
    return %c5_i32 : i32
  }
}

I am trying to get sdfg-opt to run over this main.s MLIR code.

Problems

1. The command line flag syntax is not immediately obvious

Note: I understand this is more an issue from MLIR's side, so I'll just leave some notes as a reference for future readers.

sdfg-opt --help shows something useful, but only partially:

  Compiler passes to run
    Passes:
      --convert-to-sdfg                                -   Convert SCF, Arith, Math and Memref dialect to SDFG dialect
        --main-func-name=<string>                      - Specify which func should be seen as the main func
      --linalg-to-sdfg                                 -   Convert Linalg dialect to SDFG dialect
      --lower-sdfg                                     -   Convert SDFG dialect to Func, CF, Memref and SCF dialects

It took me a good while to figure out that the only recognized syntax is:

sdfg-opt --convert-to-sdfg=main-func-name=example main.s

2. The main-func-name argument isn't respected

With the above command, this is all the output I get:

module {
}

I could not find any command line that would make sdfg-opt emit converted MLIR in sdfg dialect. The only way to make it work is to rename func.func @example into func.func @main.

Moreover, if the function is @main, then sdfg-opt works properly regardless of what the CLI argument value to main-func-name is (even garbage). For example:

sdfg-opt --convert-to-sdfg=main-func-name="@#$^&*" main.s

It seems like main-func-name is completely disregarded.

Utility

If main-func-name is fixed, then I can selectively run sdfg-opt through computation code while having separate facilities for handling I/O, enabling me to work around #29.

[Berke-Ates]

Thanks for the comprehensive issue!
Indeed the main-func-name flag is a work in progress and currently ignored.
I will implement it as soon as possible.