Upstreaming from our MLIR python compiler project

[ftynse]

Do you have tests for this so we can see roughly what the effects on the IR and the limitations are?

@Hardcode84

CfgToScfPass - our frontend outputs IR in CFG form and middle level expects SCF, so we have a pass to uplift CFG to SCF (only testes on relatively small workloads for now) mlir-extensions/plier_to_scf.cpp at 2a6d65137105e869c70fd1d86ba3bb784f70f6df · intel/mlir-extensions · GitHub

In Polygeist, we have something similar using LLVM’s LoopInfo. Do you have a rough idea how your approach compares to that?

@Hardcode84

MemorySSA analysis and few optimizations based on it (store to load propagation and dead store elimination on memref) - an attempt to replicate llvm memssa in mlir, very untested and generally not yet ready for general consumption. mlir-extensions/memory_ssa.cpp at 2a6d65137105e869c70fd1d86ba3bb784f70f6df · intel/mlir-extensions · GitHub

This sounds useful, but likely needs a design discussion on how to implement it in MLIR-generic way.

@Hardcode84

UnsrideMemrefPass - our gpu lowering converts memrefs to bare pointers in gpu kernels, so this pass inserts reinterpret_casts to 1D memrefs and corresponding flat index calculation (thats what we needed memref.extract_metadata for).

This may let us lift decouple memref address computation from memref to llvm lowering. I am supportive of this in general, and would like to understand the tradeoffs. We have seen performance improvements attributable to the address computation code emitted by MLIR in the current form compared to Clang, I wouldn’t want to lose those.

cc @wsmoses