Skip to content

Conversation

@snickolls-arm
Copy link
Contributor

@snickolls-arm snickolls-arm commented Dec 18, 2025

Adds ValueSize class for handling sizes that may be unknown at compile time during phases such as value numbering, that aren't concerned with the exact numeric value (only properties such as equivalence etc.). Adds various assertions to areas of value numbering and SSA building with assumptions based on exact size values. Adds LclVarDsc::lvValueSize to produce a ValueSize for a local variable, which provides the criteria for which locals have unknown size at compile time.

Adds lvaLclSymbolicSize for handling locals that may have an unknown size at
compile time (SIZE_UNKNOWN). Adds various assertions to areas with assumptions
based on concrete size values. Updates parts of value numbering and SSA
building to use the symbolic size of the type.
@github-actions github-actions bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Dec 18, 2025
@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Dec 18, 2025
@snickolls-arm
Copy link
Contributor Author

@dotnet/arm64-contrib

@dotnet-policy-service
Copy link
Contributor

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

@snickolls-arm
Copy link
Contributor Author

@dotnet/arm64-contrib @dotnet/jit-contrib Please could I have a review for this patch? It's a precursor for supporting the rest of the local variable implementation for SVE Vector<T>, which I can also send if more context is needed.

#define TYP_U_IMPL TYP_UINT
#endif

#define SIZE_UNKNOWN UINT8_MAX
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What prevents a normal struct from having size UINT8_MAX?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

genTypeSizes for TYP_STRUCT returns 0 so it's fine?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is already TYP_UNKNOWN - can it be re-used here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

genTypeSizes for TYP_STRUCT returns 0 so it's fine?

LclVarDsc::lvExactSize will assert for structs of size 255 in this PR if I am understanding correctly.

I think having a SIZE_UNKNOWN returned by lvSymbolicSize that you can forget to check is problematic and fragile. For example, it leaks into all users of VisitLocalDefs without good confidence that everyone remembers to check for it. I would much rather have this be some kind of optional value that makes it clear when it may not be present.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would much rather have this be some kind of optional value that makes it clear when it may not be present.

Say we have unsigned lvExactSize(bool *hasUnknownSize) instead? And I'll update all the call sites to decide whether hasUnknownSize is relevant or not to the situation.

Copy link
Member

@jakobbotsch jakobbotsch Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I would rather have a struct like

struct ValueSize
{
  bool IsUnknown();
  unsigned GetSize()
  {
    assert(!IsUnknown());
    return ...;
  }
};

to be used in the few places where we want to propagate a possibly unknown size, like VisitLocalDefs. Its internal representation can represent unknown as UINT_MAX (I don't think UINT8_MAX is reasonable).

But I would keep lvExactSize as asserting that it is not called on a value of unknown size. Hopefully there won't be many places where we need to even deal with something like ValueSize.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hopefully there won't be many places where we need to even deal with something like ValueSize.

It seems to be limited to value numbering, and after implementing your suggestion I can see which areas have the potential to fire assertions more clearly. I've updated the description to reflect this better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI community-contribution Indicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants