Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make getTypeForPrimitiveValueClass treat different signs as different types #71633

Merged
merged 4 commits into from
Jul 5, 2022

Conversation

MichalPetryka
Copy link
Contributor

Fixes #71632.

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Jul 5, 2022
@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Jul 5, 2022
@ghost
Copy link

ghost commented Jul 5, 2022

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

Issue Details

Fixes #71632.

Author: MichalPetryka
Assignees: -
Labels:

area-CodeGen-coreclr

Milestone: -

@MichalPetryka MichalPetryka changed the title Make getTypeForPrimitiveValueClass treat different sizes as different types Make getTypeForPrimitiveValueClass treat different signs as different types Jul 5, 2022
@@ -3969,54 +3969,13 @@ CorInfoType CEEInfo::getTypeForPrimitiveValueClass(
}
else
{
switch (th.GetInternalCorElementType())
CorElementType elementType = th.GetInternalCorElementType();
if (elementType >= ELEMENT_TYPE_BOOLEAN && elementType <= ELEMENT_TYPE_R8
Copy link
Member

@jkotas jkotas Jul 5, 2022

Choose a reason for hiding this comment

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

We have a helper method for this. I think it should be possible to simplify the whole thing into:

TypeHandle th(clsHnd);
_ASSERTE (!th.IsGenericVariable());

CorElementType elementType = th.GetVerifierCorElementType();
if (CorIsPrimitiveType(elementtype) || elementType == ELEMENT_TYPE_PTR || ELEMENT_TYPE_FNPTR)
{
    result = asCorInfoType(elementType);
}

It looks odd that this method is handling ELEMENT_TYPE_PTR and ELEMENT_TYPE_FNPTR. It does not match the name getTypeForPrimitiveValueClass.

Is the JIT really expecting this method to handle ELEMENT_TYPE_PTR and ELEMENT_TYPE_FNPTR?

Copy link
Contributor Author

@MichalPetryka MichalPetryka Jul 5, 2022

Choose a reason for hiding this comment

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

Is the JIT really expecting this method to handle ELEMENT_TYPE_PTR and ELEMENT_TYPE_FNPTR?

Yes, for example in https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/importer.cpp#L4203

Copy link
Contributor Author

Choose a reason for hiding this comment

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

CorIsPrimitiveType would also include ELEMENT_TYPE_END, would that be okay?

Copy link
Member

Choose a reason for hiding this comment

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

Yes, for example in https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/importer.cpp#L4203

I do not see the connection between this line and the method being changed in this PR. Could you please shed some light on it?

CorIsPrimitiveType would also include ELEMENT_TYPE_END, would that be okay?

Yes, that' ok. ELEMENT_TYPE_END is never returned by as CorElementType of a type.

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 do not see the connection between this line and the method being changed in this PR. Could you please shed some light on it?

Right, wrong line, here: https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/importer.cpp#L6586

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'll try it after the CI finishes, want to see if everything's okay with the current changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jkotas Could you take a look if the musl failure that appeared after removing the pointers looks related?

Copy link
Member

Choose a reason for hiding this comment

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

The failure looks like the same as #66413 (comment) which might be related to #71439. Does not look related to your change.

Copy link
Member

Choose a reason for hiding this comment

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

The failure is unrelated and failed in other PRs - #66413 (comment)

Copy link
Member

Choose a reason for hiding this comment

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

I have opened blocking-clean-in issue #71684 on this.

When merging on red, failures should be always tracked by active blocking-clean-in issue.

@JulieLeeMSFT
Copy link
Member

cc @dotnet/jit-contrib PTAL for this community PR.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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.

Box-unbox optimization swallows InvalidCastException on different signs
5 participants