Two comments:
- LLVM IR is actually remarkably stable these days. I was able to rebase Fil-C from llvm 17 to 20 in a single day of work. In other projects I’ve maintained a LLVM pass that worked across multiple llvm versions and it was straightforward to do.
- LICM register pressure is a big issue especially when the source isn’t C or C++. I don’t think the problem here is necessarily licm. 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.
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
What would be neat is to expose all right knobs and levers so that frontend writers can benchmark a number of possibilities and choose the right values.
I can understand this is easier said than done of course.
The reason to couple it to regalloc is that you only want to remat if it saves you a spill
Admittedly, this comes up more often in non-CPU backends.
Can you give an example?
neuroelectron•1h ago
hu3•59m ago
For starters the tooling would be much slower if it required LLVM.
phplovesong•19m ago
pornel•45m ago
Optimizing compilers are basically impossible to audit, but there are tools like alive2 for checking them.