[RTG] Add simple linear scan register allocation pass #8058
Conversation
maerhart
force-pushed
the
maerhart-rtg-emit-assembly
branch
from
44b5801 to
babe1f2
Compare
maerhart
force-pushed
the
maerhart-rtg-register-allocation-pass
branch
from
1c09e5a to
1b0c7ae
Compare
maerhart
force-pushed
the
maerhart-rtg-emit-assembly
branch
from
babe1f2 to
8ed5c6e
Compare
maerhart
force-pushed
the
maerhart-rtg-register-allocation-pass
branch
from
1b0c7ae to
16bd532
Compare
| LLVM_DEBUG(llvm::dbgs() << "=== Processing test @" << testOp.getSymName() | ||
| << "\n\n"); | ||
|
|
||
| DenseMap<Operation *, unsigned> opIndices; |
There was a problem hiding this comment.
mlir has an index value built into operations. I think it is only relative to a single block. It's used/updated by dominance analysis.
| return signalPassFailure(); | ||
| } | ||
|
|
||
| // TODO: support labels and control-flow loops (jumps in general) |
There was a problem hiding this comment.
yea, this is interesting. We need to be able to deal with fixed-value jumps, jumptables, label relative jumps, etc. We will probably need an op interface for this. Something to resolve computed live ranges.
|
|
||
| // Handle virtual registers. | ||
| rtg::RegisterAttrInterface availableReg; | ||
| for (auto reg : lr->regOp.getAllowedRegs()) { |
There was a problem hiding this comment.
Are we prioritizing/ordering registers just by their declaration order or by their index? Presumably things like stack pointers should be picked last and temporary (ABI-wise) registers picked first? Obviously this shouldn't be required, but if we want to simplify entry/exit (and temporary entry/exit for calls) into tests, this might be good.
Also might be good to know what registers are touched in a region, but maybe that is an analysis later.
There was a problem hiding this comment.
Currently, registers earlier in the allowedRegisters attribute are picked first, so helper functions can be created by the payload dialect writers that add all legal registers to this list in the priority order they prefer. But we can always change that to be specified by a Dialect interface.
Yes, an analysis to check which fixed registers are already in use in the region would allow better allocation and I'm planning to add that some time later. It's not critical right now and keeps this PR simpler.
No description provided.