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, wheredefis 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
phifromx = taint(1) is controlled by thetrueedge out ofsafe(x), but the read ofxinsink(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
phinodes, and then split the data flow stepx -> phiinto two stepsx -> [input 1] phiand[input 1] phi -> phi, where[input 1] phirepresents the input intophifrom the basic block starting atx = taint. The barrier guard logic will then make sure to include[input 1] phias a barrier node (but neitherphinor[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_readare, so the solution is to treat phi reads exactly as normal phi nodes.