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

[vivek pandya]

On Thu, Sep 24, 2020 at 11:41 AM Jacob Lifshay <programmerjake at gmail.com>
wrote:

> 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?
>
LLVM can be tuned to disable all such expensive passes which are not really
helpful to given arch/ API.
This kind of compile-time comparison must be proved :)

I have watched LLVM related development since 2016 and there has been many
interesting  things
like Azul system uses LLVM for a JavaVM (for that they worked with Google
to improve PassManager)
Apple has presented their work with respect to using LLVM as backend for
their internal GPU project
Also not only GPU there has been many different arch which uses LLVM as
compiler backend (from DSP to Mircocontroller)

But there has been some criticism too mostly for JIT API.


> >
> > 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...
>
May be I don't have enough knowledge here to prove that LLVM PPC is useful
or not.

>
> >
> > 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
> PowerPC!
>
Sure, but getting WebAssmebly working on PPC may be good for getting
funding for cranelift related efforts
but in terms of timelines for  Libresoc it seems bit difficult to achieve
goals with respect to perf.

But in any case more technical analysis will be helpful on both LLVM and
Cranelift.

>
> Jacob
>
> >
> _______________________________________________
> Libre-soc-dev mailing list
> Libre-soc-dev at lists.libre-soc.org
> http://lists.libre-soc.org/mailman/listinfo/libre-soc-dev
>