Ruby: Extend barrier guards to handle phi inputs #15985
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Barrier guards are implemented using SSA; a node is guarded if it is a read of an SSA definition
def
, wheredef
is also read in a controlling condition:However, this approach does not work when a condition controls not a read, but instead input into a phi node:
In the above, the input into
phi
fromx = taint
(1) is controlled by thetrue
edge out ofsafe(x)
, but the read ofx
insink(x)
is not.In order to handle this scenario (under-the-hood) with barrier guards, we add a new type of (hidden) data flow nodes that represent input into
phi
nodes, and then split the data flow stepx -> phi
into two stepsx -> [input 1] phi
and[input 1] phi -> phi
, where[input 1] phi
represents the input intophi
from the basic block starting atx = taint
. The barrier guard logic will then make sure to include[input 1] phi
as a barrier node (but neitherphi
nor[input 2] phi
).A similar scenario can happen for phi reads:
In the above,
phi_read
(andsink(x)
) is not controlled by asafe(x)
condition. However, both inputs intophi_read
are, so the solution is to treat phi reads exactly as normal phi nodes.