search

intel / llvm

Intel staging area for llvm.org contribution. Home for Intel LLVM-based projects.
Other
1.2k stars 708 forks source link

[SYCL-MLIR] Alternate frontends #12990

Open chsasank opened 3 months ago

chsasank commented 3 months ago

Is your feature request related to a problem? Please describe

Hi, I want to be able to use SYCL abstractions and runtime but from a front end other than C++. My aim is to write BLAS at higher level in this frontend and be able to do kernel fusion with it. I can't do this in C++ because I can't do codegen.

Describe the solution you would like

Can I emit sycl-mlir for device only code and use intel unified runtime?

Describe alternatives you have considered

No response

Additional context

No response

bader commented 3 months ago

@etiotto, can you help with this question?

etiotto commented 3 months ago

You might be able to hack the SYCL-MLIR branch. However note that, currently, we aren't actively developing that branch any longer. FYI @sommerlukas

sommerlukas commented 3 months ago

@chsasank Thanks for getting in touch!

If your not using C++, what would your input language be?

Do you already have a frontend for that language that connects to MLIR?

chsasank commented 3 months ago

Thanks for the reply!

If your not using C++, what would your input language be?

I want to be able to generate kernels instead of coding them directly. This is similar to templates in C++ (but they are not very intuitive). For example, check the following from the README of PortBLAS:

portBLAS uses C++ Expression Tree templates to generate SYCL Kernels via kernel composition. Expression Tree templates are a widely used technique to implement expressions on C++, that facilitate development and composition of operations. In particular, Kernel composition in SYCL has been used in various projects to create efficient domain-specific embedded languages that enable users to easily fuse GPU kernels.

Such a feature of generating code or representing expression trees is lot more obvious in XML or in fact lisp! So my preferred front end is a LISP DSL!

Do you already have a frontend for that language that connects to MLIR?

Not yet because I was unsure if using SYCL-MLIR is a reasonable strategy because I was not able to cleanly separate it out from host compilation. Alternate plan for me is to take 'generic' compilation flow in adaptivecpp. ACPP also has sort of a runtime similar to unified runtime.

sommerlukas commented 3 months ago

If you wanted to use SYCL-MLIR (or AdaptiveCpp), you would need to generate SYCL (i.e., C++) code from your DSL. Is that the design you are aiming for?

Alternatively, you could build a MLIR frontend for your DSL and translate to MLIR dialects such as Linalg, SCF, etc. in your frontend.

Note that there also already is a plethora of other languages/APIs with an MLIR frontend for ML, which often also entails BLAS-like operations.

chsasank commented 3 months ago

If you wanted to use SYCL-MLIR (or AdaptiveCpp), you would need to generate SYCL (i.e., C++) code from your DSL.

No, I am not planning to generate C++ code. I am hoping to generate whatever IR (SYCL-MLIR?) that SYCL uses internally to abstract out built-ins of different GPU architectures. In other words, I want my DSL to be another frontend like C++.

Alternatively, you could build a MLIR frontend for your DSL and translate to MLIR dialects such as Linalg, SCF, etc. in your frontend.

Unfortunately, the translation of these dialects to device code (for all GPU devices) is not available in upstream MLIR repository. Best lowering path I see for GPU portability is to follow the lowering path of SYCL.

sommerlukas commented 3 months ago

Some support to target Intel GPUs from MLIR through SPIR-V and the MLIR ExecutionEngine was added recently. This PR here is a good starting point to follow the discussion and links to the individual components: https://github.com/llvm/llvm-project/pull/65539

mingshi2333 commented 2 months ago

May I ask why you are stopping the development of the sycl-mlir branch now, is it because the current process (host code raising from llvm ir to sycl-mlir) is not enough good? I noticed that there is a sycl-mlir branch in the clang ir repository at the moment, are you guys planning to wait for clang-ir to mature before continuing the development. @sommerlukas @etiotto .If you intend to continue the development, what can I contribute?

sommerlukas commented 1 month ago

May I ask why you are stopping the development of the sycl-mlir branch now, is it because the current process (host code raising from llvm ir to sycl-mlir) is not enough good? I noticed that there is a sycl-mlir branch in the clang ir repository at the moment, are you guys planning to wait for clang-ir to mature before continuing the development. @sommerlukas @etiotto .If you intend to continue the development, what can I contribute?

The raising approach works for a limited set of inputs for now, but generally is not a preferable solution in the MLIR ecosystem, so we are indeed exploring options with regard to other MLIR C++ frontends.

We have already done some experimentation with ClangIR and it seems like an interesting candidate for the frontend of the project. Therefore, we are currently co-supervising a Google Summer of Code project to add more OpenCL (and by extension also SYCL) capabilities to ClangIR: https://summerofcode.withgoogle.com/programs/2024/projects/aC7xQWmT

If you wanted to contribute, looking into ClangIR (there's a number of issues tagged as "Good first issue" here) or attending the ClangIR community meeting could be good starting points.

mingshi2333 commented 1 month ago

May I ask why you are stopping the development of the sycl-mlir branch now, is it because the current process (host code raising from llvm ir to sycl-mlir) is not enough good? I noticed that there is a sycl-mlir branch in the clang ir repository at the moment, are you guys planning to wait for clang-ir to mature before continuing the development. @sommerlukas @etiotto .If you intend to continue the development, what can I contribute?

The raising approach works for a limited set of inputs for now, but generally is not a preferable solution in the MLIR ecosystem, so we are indeed exploring options with regard to other MLIR C++ frontends.

We have already done some experimentation with ClangIR and it seems like an interesting candidate for the frontend of the project. Therefore, we are currently co-supervising a Google Summer of Code project to add more OpenCL (and by extension also SYCL) capabilities to ClangIR: https://summerofcode.withgoogle.com/programs/2024/projects/aC7xQWmT

If you wanted to contribute, looking into ClangIR (there's a number of issues tagged as "Good first issue" here) or attending the ClangIR community meeting could be good starting points.

Thanks, seems like community need Clang IR to be perfected, I know seven mile(the opencl GSOC mentee) and asked him for the GSOC's weekly report doc, and i will try to take part in the discussion and contribute to it.