This change builds up on http://reviews.llvm.org/D7760
It implements support for the gc.relocates tied to the invoke statepoint. It adds new 'FuncInfo::InvokeStatepointValueSlots' field to store exported gc values and uses it during visitGCRelocate.
Differential D7798
Support of the gc.relocates for invoke statepoints Authored by igor-laevsky on Feb 20 2015, 1:44 PM.
Details This change builds up on http://reviews.llvm.org/D7760 It implements support for the gc.relocates tied to the invoke statepoint. It adds new 'FuncInfo::InvokeStatepointValueSlots' field to store exported gc values and uses it during visitGCRelocate.
Diff Detail
Event TimelineComment Actions Is there a missing part to this patch? The current code doesn't seem complete/correct.
Comment Actions Please make the changes suggested in previous rounds of discussion. I do not plan to respond further until at least the minor items are addressed. If you *disagree* with a proposed change, we can discuss, but anything which can be addressed without discussion should be done before replying. Reviewing a concrete piece of code is much easier than keeping track of proposed revisions.
Comment Actions Some minor comments inline. I can't say I've fully understood this; I'll do a second, review tomorrow.
Comment Actions I think a lot of confusion were due to the two mechanisms for recording spilled values locations - one inside StatepointLowering, and one for cross basic block values in FunctionLoweringInfo. I updated diff so that only one such mechanism is left. Now we record all value locations in "StatepointRelocatedValues" map in FuncitonLoweringInfo. Also I included statepoint instruction as a key to this map to make it obvious that there could not be any collisions when we allocate different stack sots for the same values in different statepoints. This is not required for correctness, but makes reasoning about correctness a lot easier. As a side effect "RelocLocations" map is no longer possible to maintain with reasonable effort, so I removed it completely. Anyway it added a lot of complexity while serving only purpose to not emit spill loads for values with non-unique sdvalues. (I.e preventing several spill loads from the same slots) After running some experiments I see that machineCSE is capable to handle such cases for us. Also after this change it is clear that all structures inside StatepointLowering are used only during call to the "LowerStatepoint" (they are cleared at the beginning of this function). So it will be possible to remove StatepointLowering from SelectionDAG and create it only inside "LowerStatepoint".
Comment Actions Very gentle ping. I believe code is easier to understand now. If it is still hard to read - please tell me about it, I will try something else. Comment Actions I think this is mostly ready to go in. Let's do one more iteration if you don't mind. Btw, some of the GCRelocateOperands accessors you use have been renamed; but those will show up as compiler errors.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||