I'm a bit confused by what's actually stored for the allocation
hints. The MIR parser only handles the "simple" case where there's a
single hint. I don't really understand the assertion in
clearSimpleHint, or under what circumstances there are multiple hint
registers.
Details
Diff Detail
Event Timeline
As a general thought, I wonder if it would be wise to keep the MIR specific reducer passes separate from the IR ones. Either by directory or file naming conventions.
llvm/tools/llvm-reduce/deltas/ReduceVirtualRegisters.h | ||
---|---|---|
11 | Comment needs to be updated. |
Fix comment. Also not sure why every file likes to repeat this style of comment in the source and header
I've thought about that and will probably move them into a subdirectory at some point
I'm a bit confused by what's actually stored for the allocation hints. The MIR parser only handles the "simple" case where there's a single hint. I don't really understand the assertion in clearSimpleHint, or under what circumstances there are multiple hint registers.
I'm not super familiar with the regalloc hints off-hand. But it seems ARM is the only target using target-specific regalloc hints. You can search for ARMRI::RegPairEven, ARMRI::RegPairOdd, ARMRI::RegLR there. Anyway assuming they are indeed just "hints" then it should be fine to drop them...
It seems to me that clearing a hint may work with setRegAllocationHint(vreg, 0, Register()). Though maybe it would be best to create a new clearRegAllocationHint(...) API for this to make it more explicit, what do you think?
LGTM (use setRegAllocationHint or add a new clearRegAllocationHint API at your discretion).
clearSimpleHint already exists (and is used here) and as far as I can tell clears all hints, so I don't understand the naming
clearSimpleHint already exists (and is used here) and as far as I can tell clears all hints, so I don't understand the naming
Renaming that function to clearHint() and dropping the assert sounds good to me.
Comment needs to be updated.