This adds a disabled-by-default implementation of strength reduction. Atthis point the implementation should be correct, however it is currentlyboth a size and perfscore regression when it is enabled. More work willbe needed to get the heuristics right and to make it kick in for morecases.Strength reduction replaces "expensive" operations computed on everyloop iteration with cheaper ones by creating more inductionvariables. In C# terms it effectively transforms something like```private struct S{    public int A, B, C;}[MethodImpl(MethodImplOptions.NoInlining)]private static float Sum(S[] ss){    int sum = 0;    foreach (S v in ss)    {        sum += v.A;        sum += v.B;        sum += v.C;    }    return sum;}```into an equivalent```int sum = 0;ref S curS = ref ss[0];for (int i = 0; i < ss.Length; i++){  sum += curS.A;  sum += curS.B;  sum += curS.C;  curS = ref Unsafe.Add(ref curS, 1);}```With strength reduction enabled this PR thus changes codegen of thestandard `foreach` version above from```asmG_M63518_IG03:  ;; offset=0x0011       lea      r10, [rdx+2*rdx]       lea      r10, bword ptr [rcx+4*r10+0x10]       mov      r9d, dword ptr [r10]       mov      r11d, dword ptr [r10+0x04]       mov      r10d, dword ptr [r10+0x08]       add      eax, r9d       add      eax, r11d       add      eax, r10d       inc      edx       cmp      r8d, edx       jg       SHORT G_M63518_IG03;; size=36 bbWeight=4 PerfScore 39.00```to```asmG_M63518_IG04:  ;; offset=0x0011       mov      r8, rcx       mov      r10d, dword ptr [r8]       mov      r9d, dword ptr [r8+0x04]       mov      r8d, dword ptr [r8+0x08]       add      eax, r10d       add      eax, r9d       add      eax, r8d       add      rcx, 12       dec      edx       jne      SHORT G_M63518_IG04;; size=31 bbWeight=4 PerfScore 34.00```on x64. Further improvements can be made to enable better address modes.The current heuristics try to ensure that we do not actually end up withmore primary induction variables. The strength reduction only kicks inwhen it thinks that all uses of the primary IV can be replaced by thenew primary IV. However, uses inside loop exit tests are allowed to stayunreplaced by the assumption that the downwards loop transformationwill be able to get rid of them.Getting the cases around overflow right turned out to be hard andrequired reasoning about trip counts that was added in a previous PR.Generally, the issue is that we need to prove that transforming a zeroextension of an add recurrence to a 64-bit add recurrence is legal. Forexample, for a simple case of```for (int i = 0; i < arr.Length; i++)  sum += arr[i];```the IV analysis is eventually going to end up wanting to show that`zext<64>(int32 <L, 0, 1>) => int64 <L, 0, 1>` is a correcttransformation. This requires showing that the add recurrence does notstep past 2^32-1, which requires the bound on the trip count that we cannow compute. The reasoning done for both the trip count and around theoverflow is still very limited but can be improved incrementally.The implementation works by considering every primary IV of the loop inturn, and by initializing 'cursors' pointing to each use of the primaryIV. It then tries to repeatedly advance these cursors to the parent ofthe uses while it results in a new set of cursors that still compute thesame (now derived) IV. If it manages to do this once, then replacing thecursors by a new primary IV should result in the old primary IV nolonger being necessary, while having replaced some operations by cheaperones.

…ion-2

AndyAyersMS left a comment