> 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 13 hours ago | parent [-]

> 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

▲

CalChris 11 hours ago | parent [-]

> 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.

	▲	pizlonator 10 hours ago \| parent [-]
		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.