[llvm-dev] linear-scan RA

[Bruce Hoult via llvm-dev]

Another point is that it's important that the default works well for
pathological code, such as that produced by other programs.

An example I frequently see is the output from Verilator, a program which
compiles the hardware description language Verilog into C, and then
compiles that. It likes to produce *extremely* large function bodies. I've
seen cases where engineers designing a CPU make some trivial one line
change to their Verilog and see the compile time go from a couple of
seconds to many hours. Telling them to use -O0 fixes the compile time
problem, but of course then makes their simulation go much more slowly.


On Tue, Sep 11, 2018 at 1:57 PM, David A. Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > I don't want to go too deep into the discussion here; but I'd like to
> > point out that in my experience the assignment of registers is less
> > interesting/important than the problem of how to place your
> > spill/reload code, where to perform live range splitting, how to
> > accomodate your odd machine performance characteristics, ... The
> > greedy allocator does a good job in giving you the flexibility to do
> > what you need to.
>
> That reflects my experience as well.  Counting (static or dynamic)
> spills is definitely a poor way to judge an allocator.  Counting copies
> may have more merit, but by far the most important aspect is spill code
> generation, what, where and how to spill.
>
> I recently did a study varying Greedy allocation and spilling knobs and
> saw swings of 20% or more in performance.  This is highly code-dependent
> of course but it just reinforced for me that there is no good "default"
> for anyone.  Customers are always going to complain about "their" code
> and it's our job to patiently explain why what works for "their" code
> will be dreadful for "everyone else's" code.
>
> And everyone is moving to Python anyway, so ¯\_(ツ)_/¯  :)
>
>                             -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180911/1a41e6bb/attachment.html>