opencompl / lean-mlir-old Goto Github PK

opencompl/lean-mlir@cf7d682 updates to a nightly after the implementation of typed syntax. It enriches the types in some places but mostly adds bypasses, and some of these reveal parsing errors I believe.

• Review the places where the commit trusts the types
• Fix the typing issues that arise

When no arguments are passed, MLIR tool should read input from stdin. This is especially helpful for testing, as we would like to use the pipeline:

mlir-opt dialect-code.mlir --mlir-print-op-generic | MLIR 

to allow MLIR to ingest the generic form of dialect-specific code.

These two branches are probably irrelevant now:

• The changes on match-matcher should already be in rewriter which is planned for merging in the future.
• The changes on linalg-semantics should already be in linalg-theorems which is the next big branch to merge.

@bollu @math-fehr could you check these and delete them if they're indeed irrelevant?

Implement the FFI to convert our pure lean data structures into MLIR data structures

As we can now express MLIR, we should implement an interface for MLIR's LLVM dialect. This allows LEAN to interact and lower to LLVM in a pure fashion, with no LLVM library dependency, if all one wants to do is to emit LLVM. This is modeled after llvm-hs-pure

The IR stores all SSA values, basic block arguments, function names as strings. There is no infrastructure to lookup uses of a def, and the def of a given use.

• Change the parser to allow creating GUIDs for each SSAVal.
• Build data structures use2def that goes from a use to a def, and def2uses, that goes from a def to its uses, and GUID2Path that goes from a GUID to its Path, where a Path specifies how to get to a given value by walking the AST.

@math-fehr

When we reason about linalg.runRegion, we want to show that we can safely reorder running of regions.

• errors can be reordered with anything
• set can be reordered with set, because we enforce SSA: if two sets do not interfere, then they commute. If two sets try to set at the same key, and they don't set the same value, then it's an error, and this error commutes with anything. Thus, in SSA, set commutes with everything.
• get need not commute, because get can ask for something that's defined later. But if a regions obeys dominance (under the constraint of IsIsolatedFromAbove), then runRegion commutes, because I can choose to run a region either now, or later, and the region "can't tell the difference" (it's completely isolated from above, so it only knows about its input arguments).
  For this, we need a theorem about how dominance relates to getting/setting SSA values. I am unsure what precise shape this theorem must take, but it's going to be key to get a sensible version of eg. loop reversal.

For the paper, we define eg. ArithSemantics in terms of a home-grown FinInt. @ChrisHughes24 suggested we use zmod from mathlib(4). However, since mathlib is not ported yet, we shall use the binport to use zmod definitions from Lean3. Our theorems about bit fiddling will be proven entirely in lean3 (thanks a bunch to @ChrisHughes24!) We will access the statements of the theorem via the binport in Lean4.

Add a framework for implementing dataflow analysis / abstract interpretation.

The EDSL is now more powerful, and keeping both systems with different parsing power seems like it could be a problem in the longer run (and I don't think you want to support the whole crazy MLIR in P.lean and MLIRParser.lean right?).

Having decidable equality on the base types of the library would be nice. Basically, everything but the mutually-inductive ops/bbs/regions, the most complex of which is MLIRTy.

deriving instance should do the job for all except MLIRTy, TensorElem and AttrVal. The reason is that these three have n-ary child constructors with parameters like List MLIRTy, for which the deriving command cannot infer equality decision procedures due to the recursion going on. (Anything composed, eg. MLIRTy × MLIRTy, fails as well.)

We can write these manually (although it's tedious), but the second problem is that direct recursion on these constructions doesn't terminate structurally. I'm pretty sure you can't build infinite objects with this construction anyway, but I don't know how to prove the termination property even by hand.

In the meantime, I have this executable hack:

partial def MLIRTy.beq (t1 t2: MLIRTy): Bool :=
  match t1, t2 with
  | MLIRTy.fn a1 b1, MLIRTy.fn a2 b2 =>
      beq a1 a2 && beq b1 b2
  | MLIRTy.int n1, MLIRTy.int n2 =>
      n1 == n2
  | MLIRTy.float n1, MLIRTy.float n2 =>
      n1 == n2
  | MLIRTy.tuple l1, MLIRTy.tuple l2 =>
      @List.beq _ (BEq.mk beq) l1 l2
  | MLIRTy.vector l1 t1, MLIRTy.vector l2 t2 =>
      l1 == l2 && beq t1 t2
  | MLIRTy.tensor l1 t1, MLIRTy.tensor l2 t2 =>
      l1 == l2 && beq t1 t2
  | MLIRTy.user n1, MLIRTy.user n2 =>
      n1 == n2
  | _, _ =>
      false

def MLIRTy.decEq (t1 t2: MLIRTy): Decidable (Eq t1 t2) :=
  if MLIRTy.beq t1 t2 then isTrue sorry else isFalse sorry

instance: DecidableEq MLIRTy :=
  MLIRTy.decEq

But the non-termination property is still really annoying since anything recursive fails; eg. assigning a concrete Type to an MLIRTy.

section 7.1.3 (Bitwise Tricks and Techniques) of volume 4A of The Art of Computer Programming: https://www-cs-faculty.stanford.edu/~knuth/fasc1a.ps.gz

https://news.ycombinator.com/item?id=33278589

Write a small framework to reason about operational semantics.

Implement a lightweight pattern rewriter to test rewrites within our framework.