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

Don't use GT_ARR_ELEM as a location/value #54780

Merged

Conversation

SingleAccretion
Copy link
Contributor

It represents an address.

No diffs.

@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 Jun 26, 2021
@SingleAccretion SingleAccretion changed the title Don't use GT_ARR_ELEM as a location Don't use GT_ARR_ELEM as a location/value Jun 28, 2021
Copy link
Contributor

@sandreenko sandreenko left a comment

Choose a reason for hiding this comment

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

LGTM, cc @dotnet/jit-contrib

@BruceForstall
Copy link
Member

Is it surprising there are no diffs? Was that dead code?

It looks like GT_ARR_ELEM represents an address, not an array element. For that, we'll have a wrapping IND/OBJ node. Seems like the comment above GenTreeArrElem should clarify.

Should GT_ARR_ELEM return false from OperIsImplicitIndir?

What about the appearance in optAssertionGen, that indicates an expected deref?

@SingleAccretion
Copy link
Contributor Author

Is it surprising there are no diffs? Was that dead code?

Yes, that is my understanding. It appears to me that a very long time ago GT_ARR_ELEM represented an actual array element, and these appearances are the artifacts from that time.

Seems like the comment above GenTreeArrElem should clarify.

Fixed. Perhaps the best thing to do would be to rename it GT_ARR_ELEM_ADDR, but that is a more invasive change.

Should GT_ARR_ELEM return false from OperIsImplicitIndir?
What about the appearance in optAssertionGen, that indicates an expected deref?

I think those usages are correct as GT_ARR_ELEM implies a bounds check, and thus a dereference for the lengths of dimensions.

@BruceForstall
Copy link
Member

Looks like it needs a formatting fix (maybe rebase on top of #55320 and run jit-format just to be sure).

@SingleAccretion SingleAccretion force-pushed the Remove-Invalid-GT_ARR_ELEM-Uses branch from 20d6956 to fd8421a Compare July 8, 2021 15:30
@SingleAccretion
Copy link
Contributor Author

Rebased, we'll see what the CI thinks.

@SingleAccretion
Copy link
Contributor Author

Rebased, we'll see what the CI thinks.

1) dotnet-linker-tests - restore failure.
2) CoreCLR Pri0 Runtime Tests Run OSX arm64 checked - complete timeout, no tests ran.

@BruceForstall BruceForstall merged commit fdbca22 into dotnet:main Jul 8, 2021
@SingleAccretion SingleAccretion deleted the Remove-Invalid-GT_ARR_ELEM-Uses branch July 8, 2021 21:20
@ghost ghost locked as resolved and limited conversation to collaborators Aug 7, 2021
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants