Raise/Lower to Affine about polygeist

[wsmoses]

Definitely. @chelini is also helping look at this so looping him in. There's two approaches for doing this and its unclear which is better (each with separate set of tradeoffs).

The first approach is to modify the for loop parser (https://github.com/wsmoses/MLIR-GPU/blob/97527f81df6aab1120036572e2c727c0892e7ef3/mlir/tools/mlir-clang/Lib/clang-mlir.cc#L313) to recognize scop markings and assume all relevant loads are affine / etc.

The second approach is to lower all the code in a generic way (e.g. lower for as is right now), then in MLIR recognize that the operations are affine. Last week I finished mem2reg (ensuring all induction variables are nicely represented/etc) and started importing the "deduce structured loops from CFG loop" (https://github.com/wsmoses/MLIR-GPU/blob/71aa0d71b3e10403f01d9b005cff5200cb63f8fc/mlir/lib/Transforms/LoopRestructure.cpp#L92). It now needs to generate the corresponding MLIR out of the deduced loop.

First approach lets the compiler make assumptions about input code that might not otherwise be available, whereas the latter approach could automatically deduce affine out of generic unmarked code, proving it legal.

@chelini has started looking at the first approach so to avoid duplicated work, would you be interested in looking at the second? If not we can subdivide the first approach.

Also quick update the current (non-affine) parsing is able to parse the polybench tests I've tried and half of GPU rodinia codes (of course emitting non-affine but generic MLIR).

Also cc'ing @ftynse

[kumasento]

Hi Billy @wsmoses , this is related to what I want to have in the C-to-mlir tool, maybe I could help with this.

If I understand correctly, this issue is about parsing C code into MLIR Affine if possible. If so, the first step possibly could be locating #pragma scop in the code and then try to translate its contents into Affine. Pls let me know if you have any suggestions :)

[kumasento]

Thank you @wsmoses for your explanation :)

Since the first approach is under development, maybe it is better to leave it to @chelini . I would be happy to help with any testing involved.

For the second approach, I think it indeed sounds better for the future. I could help with this, and the LoopRestruture pass you mentioned seems to be a good start. If I understand correctly, this pass helps finding loop strutures, and the thing to do is to check whether a found loop satisfies affine constraints. It won't be very difficult to check every loop bound and load/store operation to see if it uses affine expressions. I think we could borrow some ideas from Polly as well: https://polly.llvm.org/doxygen/ScopDetection_8cpp_source.html

I need to finish settling imperfectly nested loop first in my project (kumasento/polymer#5) and then I will get back to helping with this.

[wsmoses]

Sounds good to me! Let me know when you're able and we can chat more about the intricacies of option 2.

[wsmoses]

cc'ing @vchuravy here since he mentioned potentially needing raising pass for Julia-MLIR

[vchuravy]

Would be happy enough with a Std->SCF pass, like the one we prototyped ages ago. x-ef: https://llvm.discourse.group/t/rfc-working-with-cfg-loops/564?u=vchuravy

[wsmoses]

More than likely, I imagine it will be easier and best implemented as Blocks => SCF, and then a SCF=> Affine.

[kumasento]

More than likely, I imagine it will be easier and best implemented as Blocks => SCF, and then a SCF=> Affine.

I reckon it is indeed natural to raise to SCF first and then Affine. Thank you for pointing this out :)

[wsmoses]

This is now mostly done, with the exception of raising to affine.for (currently we piggyback on emitting affine.for in scop). Raising affine.if, load, store, etc is done however!