[llvm-dev] linear-scan RA (original) (raw)

Bruce Hoult via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 11 23🔞02 PDT 2018

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>

More information about the llvm-dev mailing list