[RFC] C/C++ compiler directives for MLIR dialect lowering about polygeist

[chelini]

I would like to start a discussion on how to develop this lower_to pragma properly. I did some experiments in the directions highlighted by this RFC (see #57), applying the pragma to generate operations from the linalg dialect. To do so, I had to extend the pragma with "input" and "output" fields, which represent the input and output operands of the linalg operation. We need these fields to explicitly indicated input and output, as we cannot understand this simply by looking at the function operands. Here is an example of generating a named copy op from the linalg dialect.

#pragma lower_to(copy_op, "linalg.copy") "input"(a), "output"(b)
void copy_op(int b[3][3], int a[3][3]) {
  for (int i = 0; i < 3; i++)
    for (int j = 0; j < 3; j++)
      b[i][j] = a[i][j];
}

int main() {
  int a[3][3];
  int b[3][3];
  // CHECK: linalg.copy({{.*}}, {{.*}}) : memref<3x3xi32>, memref<3x3xi32>
  copy_op(a, b);
  return 0;
}

After this extension is fairly easy to emit linalg named ops, but I hit a problem when generating linalg generic. Specifically, a linalg generic op requires index maps for each input and output view, but we do not have them at this point. Do you have any suggestions, on how to emit linalg generic op? Or should we restrict to linalg named op only?

[wsmoses]

I wonder if perhaps the right place to do this is not as much on the call declaration, but to define a special pragma that results in an op execution itself.

Maybe something like

int a[3][3];
int b[3][3];
#pragma op linalg.generic "input"(a) "output"(b)

This way we could use various runtime parameters as part of the op?

[chelini]

@wsmoses Hi Billy, not sure what you mention with "runtime parameters". Current problems I see when emitting linalg generic ops are: 1) linalg generic requires index maps to understand the mapping between loops and input/output buffers, how can we get this if we do not bind the pragma to a given function? Still after binding to a function how we can get the access maps at this point in our codegen?. 2) Linalg generic requires you to define the computation. Again this means that we need to bind the pragma to some functions or nested loop. From the example you made above I am not so sure how we can get this information.