Comment by theresistor

Comment by theresistor a day ago

> It might be that regalloc needs to be taught to rematerialize

It knows how to rematerialize, and has for a long time, but the backend is generally more local/has less visibility than the optimizer. This causes it to struggle to consistently undo bad decisions LICM may have made.

pizlonator a day ago

> It knows how to rematerialize

That's very cool, I didn't realize that.

> but the backend is generally more local/has less visibility than the optimizer

I don't really buy that. It's operating on SSA, so it has exactly the same view as LICM in practice (to my knowledge LICM doesn't cross function boundary).

LICM can't possibly know the cost of hoisting. Regalloc does have decent visibility into cost. Hence why this feels like a regalloc remat problem to me

Reply View 2 replies

CalChris 21 hours ago

> to my knowledge LICM doesn't cross function boundary
LICM is called with runOnLoop() but is called after function inlining. Inlining enlarges functions, possibly revealing more invariants.

Reply View | 1 reply
- pizlonator 21 hours ago
  
  Sure. Any pass that is scoped to functions (or even loops, or basic blocks) will have increased scope if run after inlining, and most passes run after inlining.
  In the context of this thread, your observation is not meaningful. The point is: LICM doesn't cross function boundary and neither does regalloc, so LICM has no greater scope than regalloc.
  
  Reply View | 0 replies