[turbofan] Splintering: special case deoptimizing blocks.
This avoids a whole range traversal each time we encounter a deferred block (or a succession of them). The traversal (in the removed IsIntervalAlreadyExcluded) is unnecessary - an interval with a hole where deferred blocks are shouldn't be listed in the in/out sets of those blocks in the first place. It turns out the root cause (that appeared like we had to special case ranges with holes, as the comment described) was deferred blocks with a deoptimization call. That would place the live range in the in_set of the block, but then splitting would fail because the start and split position would be the same - this is because everywhere else, the deferred block would have at least a second instruction, other than the use - like a jump - ahead of which we'd perform the lower part of the splintering. In the usual case, this choice of a position avoids moves on the hot path (because any moves will be before the jump, but still in the deferred block). With deoptimization calls, that's not the case, there is just one instruction, the deoptimization call. So we perform the second cut of the splintering right after the block. Since there is no control flow from the deoptimization block to any functional block - the control flow goes to the exit block - the range connector won't insert moves on the hot path - although we may want to see what happens for the exit block, and maybe teach the range connector to ignore control flow appearing to come from blocks with deoptimization calls. Review URL: https://codereview.chromium.org/1323473003 Cr-Commit-Position: refs/heads/master@{#30447}
Showing
Please
register
or
sign in
to comment