On Wednesday, 2 October 2019 at 23:45:03 UTC, Roberto Rosmaninho wrote:

> Yes! I found a solution: create a CMake find for mlir (ldc have one for LLVM) and it fixes the problem: http://bit.ly/2n7xEJS

Just fixing te sentence...

On Wednesday, 2 October 2019 at 23:45:03 UTC, Roberto Rosmaninho wrote:
> On Wednesday, 2 October 2019 at 20:31:02 UTC, Johan Engelen wrote:
>> As far as I can tell, if you checkout MLIR into your local LLVM checkout [1], then it is automatically built with LLVM and the header files will be part of the LLVM install.
>
> Yes! I found a solution: create a cmake find for mlir, ldc have to mlir and it fixes the problem: http://bit.ly/2n7xEJS

This doesn't look quite right.
You should `ninja install` LLVM (set an install path using -DCMAKE_INSTALL_PREFIX="..." when running cmake to generate the ninja build file), such that you get a local LLVM installation that contains also the MLIR stuff. Are you sure that MLIR is built when building LLVM? Perhaps cmake argument -DLLVM_ENABLE_PROJECTS="mlir;compiler-rt;lld" is needed.

-Johan

On Thursday, 3 October 2019 at 06:22:35 UTC, Johan Engelen wrote:

> This doesn't look quite right.
> You should `ninja install` LLVM (set an install path using -DCMAKE_INSTALL_PREFIX="..." when running cmake to generate the ninja build file), such that you get a local LLVM installation that contains also the MLIR stuff. Are you sure that MLIR is built when building LLVM? Perhaps cmake argument -DLLVM_ENABLE_PROJECTS="mlir;compiler-rt;lld" is needed.
>
> -Johan

Actually, this is a complex question. Today, to get MLIR, you must clone LLVM and MLIR from different repositories by cloning MLIR into the LLVM projects[1]. The expectation is to have MLIR into LLVM 11 and then you will be able to get the project using the -DLLVM_ENABLE_PROJECTS, which will download the project on the same projects directory used today and referred on my CMake. I believe your point is that if users don't get this project on they LLVM, then they won't be able to use LDC, please correct me if I get it wrong. Well, the thing is I have to use some header files to implement MLIR to LDC, maybe I can put some Macros to not compile those files or codes that use MLIR if that's the main issue.

Regards,
Roberto Rosmaninho

[1] https://github.com/tensorflow/mlir#getting-started-with-mlir

On Thursday, 3 October 2019 at 12:58:38 UTC, Roberto Rosmaninho wrote:
> On Thursday, 3 October 2019 at 06:22:35 UTC, Johan Engelen wrote:
>
>> This doesn't look quite right.
>> You should `ninja install` LLVM (set an install path using -DCMAKE_INSTALL_PREFIX="..." when running cmake to generate the ninja build file), such that you get a local LLVM installation that contains also the MLIR stuff. Are you sure that MLIR is built when building LLVM? Perhaps cmake argument -DLLVM_ENABLE_PROJECTS="mlir;compiler-rt;lld" is needed.
>>
>> -Johan
>
> Actually, this is a complex question. Today, to get MLIR, you must clone LLVM and MLIR from different repositories by cloning MLIR into the LLVM projects[1]. The expectation is to have MLIR into LLVM 11 and then you will be able to get the project using the -DLLVM_ENABLE_PROJECTS, which will download the project on the same projects directory used today and referred on my CMake.

I know how MLIR is to be included into the LLVM source directory. This is the same method that compiler-rt and clang used to be before the single big LLVM repo happened recently.
But I think that also means that mlir will be installed in the LLVM installation dir. So instead of searching in "${LLVM_ROOT_DIR}/../projects/mlir" (which I think will only work with your directory layout), you should be able to find the include files in "${LLVM_ROOT_DIR}/include/mlir" no?
The benefit of that is that your MLIR branch will work for others that have mlir too (even if a distribution carries MLIR, without a user having to compiler it).

> I believe your point is that if users don't get this project on they LLVM, then they won't be able to use LDC, please correct me if I get it wrong. Well, the thing is I have to use some header files to implement MLIR to LDC, maybe I can put some Macros to not compile those files or codes that use MLIR if that's the main issue.

Separate issue, but indeed. Simply do something like this in CMake and #ifdef code that cannot be compiled without MLIR:
if(LLVM_MLIR_FOUND)
    message(STATUS "Building with MLIR support")
    add_definitions("-DLDC_LLVM_MLIR_ENABLED")
endif()

(that's exactly how SPIR-V support is added to LDC)

cheers,
  Johan

On Thursday, 3 October 2019 at 18:38:35 UTC, Johan wrote:

> I know how MLIR is to be included into the LLVM source directory. This is the same method that compiler-rt and clang used to be before the single big LLVM repo happened recently.
> But I think that also means that mlir will be installed in the LLVM installation dir. So instead of searching in "${LLVM_ROOT_DIR}/../projects/mlir" (which I think will only work with your directory layout), you should be able to find the include files in "${LLVM_ROOT_DIR}/include/mlir" no?
> The benefit of that is that your MLIR branch will work for others that have mlir too (even if a distribution carries MLIR, without a user having to compiler it).

I see, but neither clang nor compiler-rt has any code in "${LLVM_ROOT_DIR}/include/".  I think the problem here is that ${LLVM_ROOT_DIR} has the following path "~/llvm-project/llvm/build" (at least this is the path that I got here - this llvm-project is the new pattern), so to get separate projects like clang, compiler-rt , and mlir, we need to go back to llvm directory, enter the project directory and select the project we want. As far as I know, this is the build pattern for llvm, so anyone who has already installed mlir will benefit from it.

> Separate issue, but indeed. Simply do something like this in CMake and #ifdef code that cannot be compiled without MLIR:
> if(LLVM_MLIR_FOUND)
>     message(STATUS "Building with MLIR support")
>     add_definitions("-DLDC_LLVM_MLIR_ENABLED")
> endif()

Done! Thanks again!

Regards,
Roberto Rosmaninho

On Friday, 4 October 2019 at 13:07:56 UTC, Roberto Rosmaninho wrote:
> On Thursday, 3 October 2019 at 18:38:35 UTC, Johan wrote:
>
> I see, but neither clang nor compiler-rt has any code in "${LLVM_ROOT_DIR}/include/".  I think the problem here is that ${LLVM_ROOT_DIR} has the following path "~/llvm-project/llvm/build" (at least this is the path that I got here - this llvm-project is the new pattern), so to get separate projects like clang, compiler-rt , and mlir, we need to go back to llvm directory, enter the project directory and select the project we want. As far as I know, this is the build pattern for llvm, so anyone who has already installed mlir will benefit from it.

You should "install" the LLVM that you build yourself, e.g. by make install or ninja install. And then point LDC to that installation of LLVM instead of to the build dir. LLVM_ROOT_DIR should point to the installation dir, not to your build dir. That is the expected setup when building LDC. Can you try that?

-Johan

On Friday, 4 October 2019 at 14:55:08 UTC, Johan Engelen wrote:
> On Friday, 4 October 2019 at 13:07:56 UTC, Roberto Rosmaninho wrote:
>> On Thursday, 3 October 2019 at 18:38:35 UTC, Johan wrote:
>>
>> I see, but neither clang nor compiler-rt has any code in "${LLVM_ROOT_DIR}/include/".  I think the problem here is that ${LLVM_ROOT_DIR} has the following path "~/llvm-project/llvm/build" (at least this is the path that I got here - this llvm-project is the new pattern), so to get separate projects like clang, compiler-rt , and mlir, we need to go back to llvm directory, enter the project directory and select the project we want. As far as I know, this is the build pattern for llvm, so anyone who has already installed mlir will benefit from it.
>
> You should "install" the LLVM that you build yourself, e.g. by make install or ninja install. And then point LDC to that installation of LLVM instead of to the build dir. LLVM_ROOT_DIR should point to the installation dir, not to your build dir. That is the expected setup when building LDC. Can you try that?
>
> -Johan

I'd like to point out that that the wiki [1] seems confuse people.
If one follows the standard procedure described (the one I had initially
followed and that Roberto followed if I understood correctly),
the instructions make the user not install LLVM. Then, it makes them
install LDC using a temporary location of LLVM (check especially
the highlighted snippets). That in turn seems to cause problems.

Should we change that ?

[1] https://wiki.dlang.org/Building_LDC_from_source

On Friday, 4 October 2019 at 17:37:23 UTC, Stefanos Baziotis wrote:
> 
> I'd like to point out that that the wiki [1] seems confuse people.
> If one follows the standard procedure described (the one I had initially
> followed and that Roberto followed if I understood correctly),
> the instructions make the user not install LLVM. Then, it makes them
> install LDC using a temporary location of LLVM (check especially
> the highlighted snippets). That in turn seems to cause problems.
>
> Should we change that ?

Ah indeed. Yes please!

On Friday, 4 October 2019 at 18:32:55 UTC, Johan wrote:
> On Friday, 4 October 2019 at 17:37:23 UTC, Stefanos Baziotis wrote:
>> 
>> I'd like to point out that that the wiki [1] seems confuse people.
>> If one follows the standard procedure described (the one I had initially
>> followed and that Roberto followed if I understood correctly),
>> the instructions make the user not install LLVM. Then, it makes them
>> install LDC using a temporary location of LLVM (check especially
>> the highlighted snippets). That in turn seems to cause problems.
>>
>> Should we change that ?
>
> Ah indeed. Yes please!

Ok, done!

Hi everyone,
Just a kick updates about the project:

1. Compilation of D through the LLVM dialect of MLIR:
 - Model all core IR structures in LLVM: Instructions, Globals, Modules, etc.
 -- Status: Module and Function already implemented, working now on operations.

 - Traverse the AST of D to emit MLIR code.
 -- Status: Working on simple examples with integers and BinOps(+,-,x,/) so far, I'll work this last week to cover more types and operations.

CMake Status: I'm trying to compile the project on other machines to make sure that each modification doesn't crash the compiler.

Best regards,
Roberto Rosmaninho