Change Details

Currently in aliasPHI we give up if we have a PHI as an incoming value to a PHI, to avoid having O(m x n) calls to aliasCheck. This patch relaxes that slightly to allow looking through PHIs if we only end up with one value as a result. This should be fine, as in the worst case we look through n blocks to find this single value, then look through n blocks again if the value we're comparing against is also a PHI, giving O(n) where n is bounded by MaxLookupSearchDepth which we already allow GetUnderlyingObject to do. This is specifically being done in order to improve alias analysis within GVN, as GVN can introduce PHI graphs of this kind where there's only one underlying value.

By using PhiValuesAnalysis we can get all the values reachable from a phi, so we can be more precise instead of giving up when a phi has phi operands. We do however need to keep the existing code because PhiValuesAnalysis won't be available in createLegacyPMBasicAAResult.

Currently in aliasPHI we give up if we have a PHI as an incoming value to a PHI, to avoid having O(m x n) calls to aliasCheck. This patch relaxes that slightly to allow looking through PHIs if we only end up with one value as a result. This should be fine, as in the worst case we look through n blocks to find this single value, then look through n blocks again if the value we're comparing against is also a PHIBy using PhiValuesAnalysis we can get all the values reachable from a phi, giving O(n) where n is bounded by MaxLookupSearchDepth which we already allow GetUnderlyingObject to do. This is specifically being done in order to improve alias analysis within GVN,so we can be more precise instead of giving up when a phi has phi operands. as GVN can introduce PHI graphs of this kind where there's only one underlying valueWe do however need to keep the existing code because PhiValuesAnalysis won't be available in createLegacyPMBasicAAResult.