[HN Gopher] Cranelift, Part 2: Compiler Efficiency, CFGs, and a ...
___________________________________________________________________
Cranelift, Part 2: Compiler Efficiency, CFGs, and a Branch Peephole
Optimizer
Author : lukastyrychtr
Score : 105 points
Date : 2021-02-20 16:37 UTC (6 hours ago)
(HTM) web link (cfallin.org)
(TXT) w3m dump (cfallin.org)
| psykotic wrote:
| In a register-allocating one-pass backend you by necessity decide
| the register/stack map for a given label the first time you emit
| a branch that targets it. As a result you never have a problem
| with critical edges for two-way branches because the fall-through
| cannot be targeted directly by other branches; you always have a
| (possibly trivial) block for the fall-through edge with only one
| predecessor. Example: // The jump_if emits
| shuffle/spill/fill code before the // conditional jump
| to conform to the L1 register/stack // map. If the L1
| map hasn't been created yet, we use // the intersection
| of our map with the conservative // live set (perhaps
| from the lexical scope) for L1 // in which case there's
| nothing to emit except the jump. jump_if(value, L1);
| // The fall-through block starts here. // The join
| emits shuffle/spill/fill code to conform // our current
| map (which is equal to the L1 map) to // the L2 map. It
| then backpatches any existing refs // to L2 and updates
| L2's address to point here. As with // jump_if, if this
| is the first ref to L2 we just set // our current map as
| L2's map and emit no code. join(L2);
|
| Multi-way branches (typically from switch jump tables) with
| critical edges are much rarer and can be handled in a one-pass
| backend by splitting on demand (by inserting jump pads) when a
| multi-way branch target has already been referenced and had its
| map assigned. That's rare enough in practice that doing something
| more global to decide where to place the splits probably isn't
| worth it in a one-pass backend.
| nynx wrote:
| For those not in the know, cranelift is primarily used as a wasm
| compiler backend, but there is also work being done on
| integrating it into the rust compiler.
| gameswithgo wrote:
| some are hopeful it will provide a faster debug compile option,
| and/or just a non llvm dependent option
| ComputerGuru wrote:
| Indeed - it was just recommended to me over on Reddit to try
| it out as the backend for my "rust as a scripting language"
| shebang header for faster first-time compiles.
|
| https://neosmart.net/blog/2020/self-compiling-rust-code/
| eikenberry wrote:
| Last I checked it was only 30% faster than the normal Rust
| compiler. So unless that's improved significantly, it isn't
| much help as of yet.
| pizza234 wrote:
| I've checked a couple of months ago, but only on one
| relatively small project (~6k lines); the compilation time
| was reduced by 50%.
| guipsp wrote:
| 30% faster is significantly faster
| mhh__ wrote:
| Depends, 30% faster codegen is a good thing to build from
| but codegen is only a fraction of the actual compilation
| process.
| eikenberry wrote:
| It is significantly faster, just not enough to make a
| difference when the baseline is so slow.
| chrisseaton wrote:
| You can be 1% faster and be 'significantly' faster.
| 'Significantly' just tells you about variance of your
| samples. What matters is if it's _usefully_ faster.
| creata wrote:
| I think they meant "significant" as in "of importance",
| not "statistically significant".
| The_rationalist wrote:
| The 30% faster was before support for split dwarf was
| enabled for llvm, I now expect to be faster or as fast as
| cranelift for debug.
___________________________________________________________________
(page generated 2021-02-20 23:00 UTC)