This repository has been archived by the owner on Oct 15, 2020. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Merge chakra-core/ChakraCore@68cc4e864c] [1.6>1.7] [MERGE #3504 @meg…
…-gupta] Fix IV analysis when a loop modifies an induction variable of another sibling loop sharing the same loop parent Merge pull request #3504 from meg-gupta:fixiv When there are two independent loops that share the same loop parent, and the second inner loop modifies the induction variable of the first inner loop, the induction variable's changes should be marked as indeterminate. Failing which, incorrect induction variable info can flow into the parent loop, which can lead to incorrect optimizations and deadcode. Example: ``` var f = 137044716; for (var _strvar26 in VarArr0) { for (; ... ; f++) { } for (var ... in ...) { f = (e > _strvar0 & 255); } } ``` The induction variable f at the top of the outer loop ends up with incorrect bounds of (137044716, INT_MAX) incorrectly. The induction variable analysis says that this loop has a induction variable with positive changed bounds. Instead of marking it as indeterminate due to the & operation in the inner loop, because of this the min is taken as the max of the two merging lower bounds. From this bad int range, blocks get optimized away and bad things happen. The f++ operation in the first inner loop adds it as an induction variable and sets the bounds correctly. The f = (e > _strvar0 & 255); operation does not do any modification on the induction variable analysis. At the end of this block this variable does no�t get detected as changing bounds because it was not in the block's� induction variable list in the first place. This change fixes this. Fixes OS#12152925.
- Loading branch information