[Libre-soc-dev] interesting blog post about cranelift's new instruction selection pass

Jacob Lifshay programmerjake at gmail.com
Thu Sep 24 07:10:52 BST 2020

On Wed, Sep 23, 2020, 22:51 vivek pandya <vivekvpandya at gmail.com> wrote:

> IIRC there is a bug https://bugs.libre-soc.org/show_bug.cgi?id=405
> I agree that compile time can be better than LLVM but I have seem massive
> efforts from various companies to reduce compile time for LLVM like
> Global-ISel/ new pass manager is intended to do that.
> Also one should not neglect the fact that generated code quality must be
> comparable between LLVM and Cranelift.

Not necessarily, Cranelift could be used for shaders when the unoptimized
flag is set from the Vulkan API and LLVM when optimization is enabled, so
Kazan could potentially use both simultaneously (both compiled into the
same .so file or similar).

> Best thing will be to get compile time data and code quality (like
> instruction count, register usage etc) for X86/AArch64 as both LLVM and
> CraneLift has that backend.

Just be careful to not accidentally tons of expensive optimizations that
take too long to run, since the shaders will have to compiled at run-time,
so we don't want to compile for 5s and declare that to be better than
cranelift which only took 100ms to compile -- who wants to wait an extra 5s
for their web browser to open?

> For PowerPC LLVM backend is very mature now so it feels a bit hard to beat
> that with the new Cranelift backend.

The SimpleV code will be new, so there is that...

> Also will it be easier to improve LLVM PPC code gen (maily I think liveness
> and register allocation for LibreSOC HW loop) ? or Cranelift has benefits
> there because of IR and the design?

Using cranelift has the additional advantage that we can design the backend
with SimpleV and GPU applications in mind from the start, potentially
gaining more performance. We'd also get WebAssembly working in Firefox on



More information about the Libre-soc-dev mailing list