This separates the two concerns - encapsulation of traversal order; and iteration.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Is the intention to have multiple iterators live for the same AllocationOrder?
llvm/lib/CodeGen/AllocationOrder.h | ||
---|---|---|
44–45 | Can you have a reference of AllocationOrder in Iterator instead of defining multiple fields? It looks a little clearer to access parent's fields directly. |
llvm/lib/CodeGen/AllocationOrder.h | ||
---|---|---|
44–45 | With the current way, I'm leveraging the ability of constructing a view over the Order ArrayRef. Also, we could author a test very easily now, avoiding the need for a Matrix, RegClassInfo, etc (what AllocationOrder needs) - albeit currently the .h is under lib/CodeGen; but we could as a next step. |
The main goal is to avoid this:
void fooBar(AllocationOrder &Order) {
Order.rewind(); while (...Order.next()) { <lots of code> }
}
So if the while loop is large, you need to go see that the order has actually been reset. Also, the state post-while loop should be reset. The alternative I'm proposing allows allocation orders be passed around without worrying they get surprisingly mutated - so easier to read and maintain.
Hi,
I like that we take the iterator path, but I don't think the current patch is clearer than the previous implementation.
First we duplicate some logic from AllocationOrder to AllocationOrder::Iterator (see my inline comment), second, I found the AllocationOrder::getIterator not iterator friendly.
What I mean here is that I would have expected a AllocationOrder::begin and AllocationOrder::end, so that we can use range based loop and so on.
As is I don't really see the value of that refactoring.
Cheers,
-Quentin
llvm/lib/CodeGen/AllocationOrder.h | ||
---|---|---|
64 | I don't like that we duplicate the logic of AllocationOrder::isHint here. |
SGTM - I'll send first another patch with unittests for the current behavior; then refresh this one.
LGTM with nitpicks
llvm/lib/CodeGen/RegAllocGreedy.cpp | ||
---|---|---|
811 | Could we just stick to assigning PhysReg at the beginning of the loop? | |
1860 | Could you call out the type here? | |
2299 | Ditto with the use of auto | |
2617 | Ditto with the use of auto |
llvm/lib/CodeGen/RegAllocGreedy.cpp | ||
---|---|---|
811 | There's a slight nuance: In the old code, suppose we never hit line 819 (the break). Then line 821 will have a 0 PhysReg (indicating loop completed, and no reg was found) In the new code, if we just initialize PhysReg on line 812, then we'll never have a 0 PhysReg on line 826 (ok, not never - because it could be the loop is never entered). We could have I in the outer scope, and check both on line 826; or - the path I preferred - we clarify that the loop searches for a value for PhysReg. wdyt? | |
1860 | Done - also changed the type of operator*, in light of our discussion - we could type it as MCPhysReg, but I think MCRegister would also be correct, and help reduce the concept count - wdyt? |
llvm/lib/CodeGen/RegAllocGreedy.cpp | ||
---|---|---|
811 | Sounds fine. | |
1860 | I have a slight preference with MCPhysReg, but MCRegister is fine too. |
feedback
llvm/lib/CodeGen/RegAllocGreedy.cpp | ||
---|---|---|
1860 | ack - fixed here and at line 2298. Left at 2617, which before was Register, and also in RegAllocBasic, same reason. |
Can you have a reference of AllocationOrder in Iterator instead of defining multiple fields? It looks a little clearer to access parent's fields directly.