llvm dev - Mar 2021 - [RFC] Upstreaming a proper SPIR-V backend

On Wed, 3 Mar 2021 at 18:41, Ronan KERYELL <ronan-list at keryell.fr>
wrote:
> But perhaps you were considering in your sentence the case where with
> OpenMP/SYCL/CUDA/HIP you generate LLVM for the host code part and MLIR
> just for the hardware accelerator parts?

Just thinking out loud if clang couldn't be a hybrid front-end, emitting
LLVM IR and MLIR for different parts of the program (for example,
accelerators), and either use SPIRV (for supported accelerators) or lower
to LLVM IR (for the rest). This would allow us to use MLIR directly in
hybrid programming models (like OpenMP, OpenCL) and make real use of the
high-level optimisations in MLIR. Perhaps SYCL wouldn't fit here.

I'm just going back to the overall goal of MLIR and trying to see on our
current approach, what do we lower too soon to LLVM IR, so it could lower
to MLIR instead, piece wise, then lower to LLVM IR (or not) later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210303/5ab16a43/attachment.html>

On 3/3/21 12:57 PM, Renato Golin via llvm-dev wrote:
> On Wed, 3 Mar 2021 at 18:41, Ronan KERYELL <ronan-list at keryell.fr>
wrote:
>
>> But perhaps you were considering in your sentence the case where with
>> OpenMP/SYCL/CUDA/HIP you generate LLVM for the host code part and MLIR
>> just for the hardware accelerator parts?
>
> Just thinking out loud if clang couldn't be a hybrid front-end,
emitting
> LLVM IR and MLIR for different parts of the program (for example,
> accelerators), and either use SPIRV (for supported accelerators) or lower
> to LLVM IR (for the rest). This would allow us to use MLIR directly in
> hybrid programming models (like OpenMP, OpenCL) and make real use of the
> high-level optimisations in MLIR. Perhaps SYCL wouldn't fit here.
As Ronan said, OpenMP (and others) is C/C++/Fortran + some additions.
Without having a full fledged C/C++ MLIR route we won't be able to build
a toolchain I would trust, not to mention the lack of evidence we need
to go to MLIR in the first place ;)

~ Johannes

>
> I'm just going back to the overall goal of MLIR and trying to see on
our
> current approach, what do we lower too soon to LLVM IR, so it could lower
> to MLIR instead, piece wise, then lower to LLVM IR (or not) later.
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

>>>>> On Wed, 3 Mar 2021 18:57:33 +0000, Renato Golin
<rengolin at gmail.com> said:
    Renato> Just thinking out loud if clang couldn't be a hybrid
    Renato> front-end, emitting LLVM IR and MLIR for different parts of
    Renato> the program (for example, accelerators), and either use
    Renato> SPIRV (for supported accelerators) or lower to LLVM IR (for
    Renato> the rest).

At some point everything is possible.

    Renato> This would allow us to use MLIR directly in hybrid
    Renato> programming models (like OpenMP, OpenCL) and make real use
    Renato> of the high-level optimisations in MLIR. Perhaps SYCL
    Renato> wouldn't fit here.

I guess you have exchanged the words OpenCL and SYCL in this sentence.
OpenCL is like graphics shader languages: a foreign language to the
host. From the host point-of-view it is just a host foreign API managing
memory allocation on the device and controlling kernel execution on some
devices (think RPC). The advantage is that you can use OpenCL from a
COBOL host program if you want but this is another story... :-)
-- 
  Ronan KERYELL