[SAoC] MLIR Support for LDC

[Johan]

On Tuesday, 15 October 2019 at 23:09:06 UTC, Roberto Rosmaninho 
wrote:
> Hi everyone, I'm here for the last update of this 1st Milestone!

Hey Roberto,
   It's fun to read your updates, thanks :)

> So, this week I refactored the code! Unfortunately, I wrote a 
> bunch of useless code while I was trying to understand how ldc 
> does some things, but that ok...the code is much better 
> readable now, so if you have some interest in review the code 
> I'm still updating this branch:
> https://github.com/Robertorosmaninho/ldc/tree/fix-llvm-10

I hope to get the LLVM 10 fixes into LDC master soon. Then you 
can rebase on top of that to make the specific MLIR changes more 
obvious and easier to view.

> Since my last update I worked on the following tasks:
>  - Refactoring the code.
>     - I was doing some weird stuff to get access to all 
> statements, so now it's possible to declare more than 1 
> function on a program.
>     - I changed the name of the functions for the mangled name.
>     - I had some problems with function parameters as well, but 
> finally, I could fix.
>  - I made mlir less verbose (HUGE improvements here!!)
>  - Implement calls
>  - Implement one-dimensional tensors (as a static array)
>
> So far my implementation can deal with:
>  - Simple VarDeclarations
>  - Operations: +, - , x, /
>  - Declare undimensional vectors
>  - Function calls
>  - All types are integer except the output of arrays

(I didn't check if you already did this) I find it very helpful 
to look at test cases to see what functionality you are adding. 
The lit-based testsuite is very convenient for checking IR 
output. Did you already add MLIR tests there?

> Issues:
>  - MLIR is growing too fast I am more than 150 commits behind 
> HEAD and at least yesterday wasn't compiling on my Linux with 
> LLVM trunk.
>  - LLVM trunk changed some stuff and I wasn't able to compile 
> with my version of MLIR.

Don't stress out too much about not following LLVM trunk exactly. 
But also don't lag too long behind, such that the changes you 
need to make are not too big and that you keep up to date on 
impactful MLIR changes. So perhaps only pull MLIR trunk once in 2 
weeks or so.
You can try to offload some of the general LLVM trunk compile 
issues to others, by making us aware of LLVM trunk compile 
issues. I can try to help with that.

> Where I'm at each project:
> - LLVM: commit f79d8a064ce4d8846377e4abbc9a389b62f90d43 |  Wed 
> Aug 28 15:40:34 2019.
> - MLIR: I'm working on fix-llvm-10 branch so I'm behind commit 
> b50775af52281d9f38aae6c359b72dc715408df0 of Aug 30.
>
> This should be fixed next week, I will try to port my code to 
> the next stable version of each project.

LLVM trunk compilation fixes (not related to MLIR) you can submit 
as PRs to LDC. That way your branch is solely about MLIR changes, 
and not cluttered by the general LLVM changes needed.

> For the next steps:
>  - Make CMake FindMLIR more general, it seems like it's not 
> possible to reach projects directory by LLVM_ROOT_DIR on Linux 
> so I have to figure out a new way to find MLIR.

I was hoping you had solved these issues. I'm still confused by 
"reach projects directory", is it not possible to `ninja install` 
MLIR ?

>  - Extend the size of tensor and work on support for all 
> types...
>  - Create the LDC Dialect

Looking forward to the next update.

cheers,
   Johan