builder.AddInput(
Again, this is just different enough so we can't trivially fold it into the default path :|
Here: the hole_nan to the_hole_value conversion, which doesn't happen in AddVirtualObjectNestedValue.
if (value.is_hole_nan()) {
Here: again the hole conversion, and NewHeapNumberFromBits, whereas BuildNestedValue just does NewNumber (including smi canonicalization and I suppose without preserving the bit pattern).
Maybe we could pull these things into AddVirtualObjectNestedValue/BuildNestedValue and just take the normal paths instead..
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
Again, this is just different enough so we can't trivially fold it into the default path :|
Here: the hole_nan to the_hole_value conversion, which doesn't happen in AddVirtualObjectNestedValue.
Acknowledged
if (value.is_hole_nan()) {
Here: again the hole conversion, and NewHeapNumberFromBits, whereas BuildNestedValue just does NewNumber (including smi canonicalization and I suppose without preserving the bit pattern).
Maybe we could pull these things into AddVirtualObjectNestedValue/BuildNestedValue and just take the normal paths instead..
I guess the advantage of using `GetDeoptLiteral(roots.the_hole_value()))` is a smaller `TranslationArray`. We could probably avoid creating the HN here as well... I don't know why we do it. My guess the deoptimizer unwraps the HN. Maybe we could send the raw values instead.
BuildNestedValue probably doesn't care about holes, but I am not sure.
Making the code more consistent in all code paths sgtm.
const vobj::ObjectLayout* object_layout_ = nullptr;
Do we ever create a VO without ObjectLayout?
I guess this could also be a `const vobj::ObjectLayout&` to avoid nullptr issues.
It could be a follow up...
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +2 |
Thanks for the review!
if (value.is_hole_nan()) {
Victor GomesHere: again the hole conversion, and NewHeapNumberFromBits, whereas BuildNestedValue just does NewNumber (including smi canonicalization and I suppose without preserving the bit pattern).
Maybe we could pull these things into AddVirtualObjectNestedValue/BuildNestedValue and just take the normal paths instead..
I guess the advantage of using `GetDeoptLiteral(roots.the_hole_value()))` is a smaller `TranslationArray`. We could probably avoid creating the HN here as well... I don't know why we do it. My guess the deoptimizer unwraps the HN. Maybe we could send the raw values instead.
BuildNestedValue probably doesn't care about holes, but I am not sure.
Making the code more consistent in all code paths sgtm.
Ack. I will have a closer look once this cl series is complete.
const vobj::ObjectLayout* object_layout_ = nullptr;
Do we ever create a VO without ObjectLayout?
I guess this could also be a `const vobj::ObjectLayout&` to avoid nullptr issues.
It could be a follow up...
It could, yes, but I don't see much difference vs. the current impl with a DCHECK_NOT_NULL. We never dynamically select an ObjectLayout.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[maglev] Port FixedDoubleArray to new VirtualObject layout
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |