[maglev] Fix DCHECK in RegisterMerge with constants
Merging register values can encounter constants, which are loadable but don't have spill slots. Add support for these (in practice this is the same behaviour, we're just fixing a DCHECK). Bug: v8:7700 Change-Id: I9ab8ba1fc3a3a64fe16668bb317ad02f878f5849 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749579 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81611}
This commit is contained in:
parent
307dffed3c
commit
871ed8cf08
@ -815,9 +815,14 @@ class ValueNode : public Node {
|
||||
}
|
||||
|
||||
compiler::AllocatedOperand spill_slot() const {
|
||||
DCHECK_EQ(state_, kSpillOrHint);
|
||||
DCHECK(is_spilled());
|
||||
return compiler::AllocatedOperand::cast(spill_or_hint_);
|
||||
return compiler::AllocatedOperand::cast(loadable_slot());
|
||||
}
|
||||
|
||||
compiler::InstructionOperand loadable_slot() const {
|
||||
DCHECK_EQ(state_, kSpillOrHint);
|
||||
DCHECK(is_loadable());
|
||||
return spill_or_hint_;
|
||||
}
|
||||
|
||||
void mark_use(NodeIdT id, InputLocation* input_location) {
|
||||
|
@ -1527,12 +1527,10 @@ void StraightForwardRegisterAllocator::MergeRegisterValues(ControlNode* control,
|
||||
merge->node = node == nullptr ? incoming : node;
|
||||
|
||||
// If the register is unallocated at the merge point, allocation so far
|
||||
// is the spill slot for the incoming value. Otherwise all incoming
|
||||
// is the loadable slot for the incoming value. Otherwise all incoming
|
||||
// branches agree that the current node is in the register info.
|
||||
compiler::AllocatedOperand info_so_far =
|
||||
node == nullptr
|
||||
? compiler::AllocatedOperand::cast(incoming->spill_slot())
|
||||
: register_info;
|
||||
compiler::InstructionOperand info_so_far =
|
||||
node == nullptr ? incoming->loadable_slot() : register_info;
|
||||
|
||||
// Initialize the entire array with info_so_far since we don't know in
|
||||
// which order we've seen the predecessors so far. Predecessors we
|
||||
|
Loading…
Reference in New Issue
Block a user