Skip to content
New issue

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

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

Already on GitHub? # to your account

Intrinsify RuntimeHelpers.CreateSpan on Mono #80762

Closed
Tracked by #43051
EgorBo opened this issue Jan 18, 2023 · 8 comments · Fixed by #82093
Closed
Tracked by #43051

Intrinsify RuntimeHelpers.CreateSpan on Mono #80762

EgorBo opened this issue Jan 18, 2023 · 8 comments · Fixed by #82093
Assignees
Milestone

Comments

@EgorBo
Copy link
Member

EgorBo commented Jan 18, 2023

Context: a lot of benchmarks regressed on Mono after #79461 and #80668

On CoreCLR the following snippet (compiled with the most recent Roslyn):

static int GetInt8(int index)
{
    ReadOnlySpan<byte> RVA = new byte[] { 1, 2, 3, 4 };
    return RVA[index];
}

static int GetInt32(int index)
{
    ReadOnlySpan<int> RVA = new int[] { 1, 2, 3, 4 };
    return RVA[index];
}

produces more or less the same codegen while IL is quite different - in case of ReadOnlySpan<int> a RuntimeHelpers.CreateSpan call is emitted by Roslyn (to handle endianness). CoreCLR has a JIT intrinsics implemented by @davidwrighton in #61079 that helps it to achieve perfect codegen here. As that PR states, Mono doesn't have that intrinsic so CreateSpan ends up calling an icall in vm (ves_icall_System_Runtime_CompilerServices_RuntimeHelpers_GetSpanDataFrom)

@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 Jan 18, 2023
@ghost ghost added the untriaged New issue has not been triaged by the area owner label Jan 18, 2023
@ghost
Copy link

ghost commented Jan 18, 2023

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

Issue Details

Context: a lot of benchmarks regressed on Mono after #79461 and #80668

On CoreCLR the following snippet (compiled with the most recent Roslyn):

static int GetInt8(int index)
{
    ReadOnlySpan<byte> RVA = new byte[] { 1, 2, 3, 4 };
    return RVA[index];
}

static int GetInt32(int index)
{
    ReadOnlySpan<int> RVA = new int[] { 1, 2, 3, 4 };
    return RVA[index];
}

produces more or less the same codegen while IL is quite different - in case of ReadOnlySpan<int> a RuntimeHelpers.CreateSpan call is emitted by Roslyn (to handle endianness). CoreCLR has a JIT intrinsics implemented by @davidwrighton in #61079 that helps it to achieve perfect codegen here. As that PR states, Mono doesn't have that intrinsic so CreateSpan ends up calling an icall in vm (ves_icall_System_Runtime_CompilerServices_RuntimeHelpers_GetSpanDataFrom)

Author: EgorBo
Assignees: -
Labels:

area-CodeGen-coreclr

Milestone: -

@ghost
Copy link

ghost commented Jan 18, 2023

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

Issue Details

Context: a lot of benchmarks regressed on Mono after #79461 and #80668

On CoreCLR the following snippet (compiled with the most recent Roslyn):

static int GetInt8(int index)
{
    ReadOnlySpan<byte> RVA = new byte[] { 1, 2, 3, 4 };
    return RVA[index];
}

static int GetInt32(int index)
{
    ReadOnlySpan<int> RVA = new int[] { 1, 2, 3, 4 };
    return RVA[index];
}

produces more or less the same codegen while IL is quite different - in case of ReadOnlySpan<int> a RuntimeHelpers.CreateSpan call is emitted by Roslyn (to handle endianness). CoreCLR has a JIT intrinsics implemented by @davidwrighton in #61079 that helps it to achieve perfect codegen here. As that PR states, Mono doesn't have that intrinsic so CreateSpan ends up calling an icall in vm (ves_icall_System_Runtime_CompilerServices_RuntimeHelpers_GetSpanDataFrom)

Author: EgorBo
Assignees: vargaz, BrzVlad
Labels:

area-Codegen-JIT-mono, area-Codegen-AOT-mono, area-Codegen-Interpreter-mono

Milestone: 8.0.0

@lewing
Copy link
Member

lewing commented Jan 18, 2023

@SamMonoRT
Copy link
Member

@jandupej has started work on addressing this

@jandupej
Copy link
Member

The issue has been addressed in #81695, closing.

@vargaz
Copy link
Contributor

vargaz commented Feb 13, 2023

The interpreter support is still missing.

@SamMonoRT
Copy link
Member

@BrzVlad will be working on Interpreter support

@vargaz vargaz reopened this Feb 13, 2023
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Feb 14, 2023
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Feb 15, 2023
@jandupej
Copy link
Member

Remaining perf issues on Linux AOT x64: #83330

@ghost ghost locked as resolved and limited conversation to collaborators Apr 12, 2023
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants