Skip to content

Support loop cloning of class member arrays #77071

Description

@BruceForstall

Currently, if the array being iterated is a class member (and not a function local), we can't analyze the access (e.g., can't determine if the array object is loop-invariant).

e.g.,

public class Program
{
    int[] array = new int[1000003];

    public int Sum()
    {
        int sum = 0;
        for (int i = 0; i < array.Length; i++)
            sum += array[i];
        return sum;
    }
}

category:cq
theme:loop-opt
skill-level:expert
cost:large
impact:medium

Activity

  1. added
    area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
    on Oct 15, 2022
  2. added this to the 8.0.0 milestone on Oct 15, 2022
  3. modified the milestones: 8.0.0, 9.0.0 on Jul 7, 2023
  4. ChrML commented on Apr 16, 2024

    @ChrML

    Just a question out of curiousity: I guess you can't guarantee that someone else doesn't change the array reference while looping.

    What would be the criterias for assuming that the code up to the element-access is "short" enough / that it's safe to fetch the instance once, check and then access it without bound-checks?

  5. added
    Priority:2Work that is important, but not critical for the release
    on May 7, 2024
  6. removed
    Priority:2Work that is important, but not critical for the release
    on Jun 13, 2024
  7. modified the milestones: 9.0.0, 10.0.0 on Jul 25, 2024
  8. EgorBo commented on Mar 20, 2025

    @EgorBo
    Member

    Just a question out of curiousity: I guess you can't guarantee that someone else doesn't change the array reference while looping.

    What would be the criterias for assuming that the code up to the element-access is "short" enough / that it's safe to fetch the instance once, check and then access it without bound-checks?

    Our memory model allows us to hoist the array access regardless of the loop's length. Developers are expected to use volatile if that behavior is not desired (preferably, lock actually since lock-free is extremely difficult to do correctly).

  9. removed this from the 10.0.0 milestone on May 15, 2025
  10. added this to the Future milestone on May 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions