You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we can see the canonicalize pass has removed v16 <- phi(v25, v14) alive T{Uint8List?} and made the instance call use v7.
This can be an issue if further optimization passes inline the instance call and move instructions above the AssertAssignable. (e.g. lower InstanceCall to LoadField/GenericCheckBound/AccessBytes and move LoadField before the AssertAssignable).
/cc @mraleph@alexmarkov Do you agree that we should avoid breaking such control-dependency-as-data-dependency chains during optimization?
The text was updated successfully, but these errors were encountered:
mkustermann
added
the
area-vm
Use area-vm for VM related issues, including code coverage, FFI, and the AOT and JIT backends.
label
Oct 2, 2020
Yeah I think it might be a problem. I think when removing a Phi which has data dependency definitions as it's inputs we should consider replacing this phi with a redefinition instead of just dropping it.
@mraleph That's a good idea - we can insert Redefinition into the beginning of the basic block when removing Phi if flow_graph->is_licm_allowed() and phi is replaced with a value which bypassed at least one redefinition.
Maybe we can also implement a pass (like FlowGraph::RenameUsesDominatedByRedefinitions) which would run immediately before LICM and would restore/establish dependencies where we lost them during graph transformations. This would make maintaining control dependencies less fragile.
For this code:
Before Canonicalize:
After canonicalize:
As we can see the canonicalize pass has removed
v16 <- phi(v25, v14) alive T{Uint8List?}
and made the instance call usev7
.This can be an issue if further optimization passes inline the instance call and move instructions above the
AssertAssignable
. (e.g. lower InstanceCall to LoadField/GenericCheckBound/AccessBytes and move LoadField before theAssertAssignable
)./cc @mraleph @alexmarkov Do you agree that we should avoid breaking such control-dependency-as-data-dependency chains during optimization?
The text was updated successfully, but these errors were encountered: