[libre-riscv-dev] llvm review

[Jacob Lifshay]

On Mon, Feb 4, 2019, 20:17 Luke Kenneth Casson Leighton <lkcl at lkcl.net
wrote:

> Hi Jacob, Robin (cc'd) says this below
> https://reviews.llvm.org/D57504

Yeah, I did see.

>
> Robin it is worthwhile pointing out that the vulkan implementation Kazan is
> a direct SPIRV to LLVM IR compiler, you may be expecting that we intend to
> add the vector intrinsics to eg clang-llvm, when that is in fact being
> bypassed.
>
> We do not even need or intend vectorisation to be added to rust-llvm, as
> the vulkan driver which happens to be in rust is near-exclusively a SPIRV
> to IR compiler. It could just as well be written in Visual Basic :)
>
Please, not VB 1.0, done that before, it's a mess. :)

I am designing the SPIR-V frontend so that it translates from SPIR-V
instructions directly to vectorized ir through a compiler agnostic API having
variable length vectors with short subvectors, with the intention that we
can support multiple versions of llvm by having multiple/shared
implementations of the API, as well as support other compilers like
libgccjit and cranelift. llvm will never have to deal with vectorizing the
code itself. The current implementation is targeting x86_64 and llvm 7 for
stability. Once the vulkan driver is partially functioning, we will add an
API implementation that uses llvm master and the risc-v backend with our
llvm additions for adding support for our RISC-V extension(s).

>
> Will take a look, the idea is to design everything simultaneously, to cover
> the triple roles of CPU, GPU and VPU.
>
> ---
>
> king". In fact, I am by now inclined to propose that Jacob and
> collaborators start out by expressing their architecture's operations with
> target-specific intrinsics that also use the attributes introduced here
> (especially since none of the typical vectorizers are equipped to generate
> the sort of code they want from scalar code using e.g. float
>
If nothing else in llvm ends up working, we may have to fall back on target
specific intrinsics, though that would make supporting software rendering
on anything but our gpu basically impossible without rewriting the compiler
API implementation for every target. Kazan (the Vulkan driver) is intended
to support software rendering on all supported llvm backends, allowing it
to be used for fallback graphics, for rendering on servers, and for other
similar applications.

Jacob Lifshay