RuntimeHelpers.CreateSpan<T> by davidwrighton · Pull Request #61079 · dotnet/runtime

davidwrighton · 2021-11-02T00:46:02Z

Implement RuntimeHelpers.CreateSpan<T>#60948

Implementation provides for

Both non-intrinsic and intrinsic implementations in CoreCLR
Non-intrinsic implementation in Mono
- Mono implementation also implements untested big endian support

* Add non-intrinsic implementation for CreateSpan<T>. * Validate RVA field for Span<T> Co-authored-by: David Wrighton <davidwr@microsoft.com>

* Implement CreateSpan<T> intrinsic.

…t is legal for them to be of a primitive type. Fix the CreateSpan intrinsic to handle that case (dotnet#60525)

… does not support CreateSpan

ghost · 2021-11-02T00:46:07Z

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

ghost · 2021-11-02T00:46:07Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

davidwrighton · 2021-11-02T00:49:21Z

@echesakov Could you help us out with the implementation of the intrinsic? I'd like to remove the hackathon comments and make the codegen as clean as possible. (Currently the codegen creates a ReadOnlySpan local, and then copies from that local whenever its used, but that seems like it should be fixable. Also, there are some hackathon comments in the IL intrinsic implementation that I'd like guidance on.

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

…e into CreateSpanIntrinsic

jaredpar · 2021-11-02T20:00:53Z

Couple items I didn't see covered in the issue / PR

What is the expected behavior when a type is provided which is not compatible with the current implementation? For example CreateSpan<Guid>() ?
Why doesn't this have a where T : struct constraint? I can definitely see a world where we allowed any unmanaged type here but reference types seems very hard to envision?
Lets say in the future we expand the set of types for which this API is legal. For example if we allowed for any unmanaged type and not just primitives. How is the C# compiler supposed to detect the set of legal types at compilation time? Basically how can it tell when it's compiling against versions of this API which only support primitive and those which support all unmanaged types? Will we add a runtime feature flag?

EgorBo · 2021-11-02T20:14:20Z

What is the expected behavior when a type is provided which is not compatible with the current implementation? For example CreateSpan<Guid>() ?

Judging by the current implementation it throws ArgumentException for anything other than primitives and enums

Why doesn't this have a where T : struct constraint? I can definitely see a world where we allowed any unmanaged type here but reference types seems very hard to envision?

Will it protect the API from passing structs with reference types inside? if not why bother 🙂 It needs a sort of "T : nogc" constraint, similar to T : unamanged

jaredpar · 2021-11-02T20:18:14Z

Will it protect the API from passing structs with reference types inside?

That is what where T: unmanaged is for but it's also lacking here

if not why bother 🙂

This is an argument I'm honestly having a hard time responding to. The goal of the typed languages is to move errors that occur at runtime to compile time. There is no path I'm aware of that would ever allow this to work with reference types hence why allow it as an argument when there is an easy option to stop it?

jkotas · 2021-11-02T20:25:13Z

The constraint does not add much here since this API can be only ever meaningfully used by compiler generated code. We can add it. It does not matter.

well, if we add a struct constraint now we will never be able to drop/change it.

Yes, relaxing constraint is not considered a breaking change.

Basically how can it tell when it's compiling against versions of this API which only support primitive and those which support all unmanaged types? Will we add a runtime feature flag?

Yes, it is what runtime feature flags are for.

EgorBo · 2021-11-02T20:35:19Z

The constraint does not add much here since this API can be only ever meaningfully used by compiler generated code.

oops, yeah it makes my comments completely irrelevant, sorry for my 5 cents @jaredpar

davidwrighton · 2021-11-02T21:55:44Z

@jaredpar, @jkotas, @EgorBo I don't see why we would want to use a constraint here. We don't have the ability to actually express a useful constraint that actually covers the actual behavior, all usage of this api is actually compiler controlled, and while a struct or unmanaged constraint seems like it might make sense, I can also see counterexamples. For instance, what if we decided to come up with an encoding for a ReadOnlySpan that specified that the PE file would hold the data as a series of null terminated utf8 strings and make that useable from RuntimeHelpers.InitializeArray and this new api.

While not in the api proposal, violations of the preconditions are documented in the api comments (which will turn into documentation) to specify that violations will turn into ArgumentException.

jaredpar · 2021-11-02T22:11:31Z

all usage of this api is actually compiler controlled,

All of the intended usage is compiler controlled. There is nothing stopping users from calling this directly.

I do understand and agree with the reasons of there isn't a perfect constraint here and hence we should do none. I would lean towards where T : struct but I don't feel that strongly about it.

I don't buy the reasoning in this thread about "this is a compiler API" factoring into the decision though. It's an API, if we have the right tools we should be expressing the right contracts.

While not in the api proposal, violations of the preconditions are documented in the api comments (which will turn into documentation) to specify that violations will turn into ArgumentException.

Sounds reasonable.

jkotas · 2021-11-02T22:48:04Z

+ public static ReadOnlySpan<T> CreateSpan<T>(RuntimeFieldHandle fldHandle)
+ {
+ unsafe
+ {
+ void* data = default;
+ int count = default;
+ GetSpanDataFrom(fldHandle, typeof(T).TypeHandle, &data, &count);
+ return new ReadOnlySpan<T>(data, count);
+ }
+ }


Suggested change
publicstaticReadOnlySpan<T>CreateSpan<T>(RuntimeFieldHandlefldHandle)
{
unsafe
{
void*data=default;
intcount=default;
GetSpanDataFrom(fldHandle,typeof(T).TypeHandle,&data,&count);
returnnewReadOnlySpan<T>(data,count);
}
}
publicstaticunsafeReadOnlySpan<T>CreateSpan<T>(RuntimeFieldHandlefldHandle)
=>newReadOnlySpan<T>(GetSpanDataFrom(fldHandle,typeof(T).TypeHandle,outintlength),length);
Nit: You can make it one-liner if you change GetSpanDataFrom to return the pointer.

vargaz · 2021-11-03T00:25:47Z

+ const char *rvaData;
+
+ if (!image_is_dynamic (m_class_get_image (klass)))
+ {


This and other places should use K&R indentation.

…nsic

stephentoub · 2021-11-30T20:58:15Z

Awesome to this go in! Is someone on point to follow-up on productizing the prototype on the Roslyn side of things?

AaronRobinsonMSFTand others added 9 commits November 1, 2021 17:01

Add non-intrinsic implementation for CreateSpan<T>. (dotnet#60451)
f5a5d9c
* Add non-intrinsic implementation for CreateSpan<T>. * Validate RVA field for Span<T> Co-authored-by: David Wrighton <davidwr@microsoft.com>

[hackathon] Implement CreateSpan<T> intrinsic. (dotnet#60498)
52a7dd3
* Implement CreateSpan<T> intrinsic.

Fix CreateSpan build failure (dotnet#60510)
5917c2c

Most static initialization data fields are of a structure type, but i…
fc74779
…t is legal for them to be of a primitive type. Fix the CreateSpan intrinsic to handle that case (dotnet#60525)

Fix CreateSpan in R2R code generation
b18bb64

Convert CreateSpan test to IL
1950ef1

Remove CreateSpan C# based test as the Roslyn used in the main branch…
320452c
… does not support CreateSpan

Add xml doc comment for CreateSpan api
415ea45

Fix xml comment
0636c79

ghost added the new-api-needs-documentation label Nov 2, 2021

jkotas reviewed Nov 2, 2021
View reviewed changes

Comment threadsrc/coreclr/jit/importer.cpp

jkotas reviewed Nov 2, 2021
View reviewed changes

Comment threadsrc/coreclr/tools/Common/JitInterface/CorInfoImpl.cs Outdated

jkotas reviewed Nov 2, 2021
View reviewed changes

Comment threadsrc/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

jkotas reviewed Nov 2, 2021
View reviewed changes

Comment threadsrc/coreclr/tools/Common/TypeSystem/Common/Instantiation.cs Outdated

davidwrightonand others added 2 commits November 1, 2021 18:04

Update src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs
cd636f0
Co-authored-by: Jan Kotas <jkotas@microsoft.com>

Update src/coreclr/tools/Common/TypeSystem/Common/Instantiation.cs
510c0d2
Co-authored-by: Jan Kotas <jkotas@microsoft.com>

jkotas reviewed Nov 2, 2021
View reviewed changes

Comment threadsrc/coreclr/tools/Common/JitInterface/CorInfoImpl.cs Outdated

Apply suggestions from code review
0dac4b1

SingleAccretion reviewed Nov 2, 2021
View reviewed changes

Comment threadsrc/coreclr/jit/importer.cpp Outdated

MichalStrehovsky reviewed Nov 2, 2021
View reviewed changes

Comment threadsrc/coreclr/tools/Common/TypeSystem/Common/Instantiation.cs Outdated

EgorBo reviewed Nov 2, 2021
View reviewed changes

Comment threadsrc/coreclr/jit/importer.cpp

EgorBo reviewed Nov 2, 2021
View reviewed changes

Comment threadsrc/libraries/System.Private.CoreLib/src/System/Runtime/CompilerServices/RuntimeHelpers.cs Outdated

davidwrighton added 2 commits November 2, 2021 11:54

Update based on code review feedback to improve generated code
4987e01

Merge branch 'CreateSpanIntrinsic' of github.com:davidwrighton/runtim…
f6b01c3
…e into CreateSpanIntrinsic

Fix JIT formatting issues
2356d02

davidwrighton requested a review from AaronRobinsonMSFT November 2, 2021 21:58

davidwrighton marked this pull request as ready for review November 2, 2021 21:59

davidwrighton requested review from lambdageek, marek-safar, thaystg and vargaz as code owners November 2, 2021 21:59

AaronRobinsonMSFT approved these changes Nov 2, 2021
View reviewed changes

Comment threadsrc/coreclr/classlibnative/bcltype/arraynative.cpp

jkotas reviewed Nov 2, 2021
View reviewed changes

MustExpand intrinsic for NativeAOT
fbf632b

vargaz reviewed Nov 3, 2021
View reviewed changes

Comment threadsrc/mono/mono/metadata/class.c

vargaz reviewed Nov 3, 2021
View reviewed changes

davidwrighton added 5 commits November 17, 2021 18:01

Respond to code review
6aec0ab

Merge branch 'main' of github.com:dotnet/runtime into CreateSpanIntri…
7546a6f
…nsic

Adjust to changes in JIT
38f080c

Fix HELPER_METHOD_FRAME define usage
34303ee

Merge branch 'main' of github.com:dotnet/runtime into CreateSpanIntri…
2b0aeb6
…nsic

davidwrighton merged commit 3efb476 into dotnet:mainNov 30, 2021

joshpeterson mentioned this pull request Nov 30, 2021
bot upstream main merge 2021 11 30 Unity-Technologies/runtime#11
Closed

joshpeterson mentioned this pull request Dec 1, 2021
bot upstream main merge 2021 12 01 Unity-Technologies/runtime#12
Closed

kunalspathak mentioned this pull request Dec 2, 2021
jit/intrinsics/createspan_il/createspan_il.sh #62285
Closed

marek-safar mentioned this pull request Dec 3, 2021
Pull Requests CI Tests Holes Tracker #62276
Open

EgorBo mentioned this pull request Dec 4, 2021
Including FastFloat in parsing process #62301
Merged

ghost locked as resolved and limited conversation to collaborators Dec 31, 2021

davidwrighton deleted the CreateSpanIntrinsic branch April 13, 2023 18:50

-publicstaticReadOnlySpan<T>CreateSpan<T>(RuntimeFieldHandlefldHandle)
-{
- unsafe
-{
-void*data=default;
-intcount=default;
-GetSpanDataFrom(fldHandle,typeof(T).TypeHandle,&data,&count);
-returnnewReadOnlySpan<T>(data,count);
-}
-}
+publicstaticunsafeReadOnlySpan<T>CreateSpan<T>(RuntimeFieldHandlefldHandle)
+=>newReadOnlySpan<T>(GetSpanDataFrom(fldHandle,typeof(T).TypeHandle,outintlength),length);

Uh oh!

Conversation

davidwrighton commented Nov 2, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Nov 2, 2021

Uh oh!

ghost commented Nov 2, 2021

Uh oh!

davidwrighton commented Nov 2, 2021

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jaredpar commented Nov 2, 2021

Uh oh!

EgorBo commented Nov 2, 2021

Uh oh!

jaredpar commented Nov 2, 2021

Uh oh!

jkotas commented Nov 2, 2021

Uh oh!

EgorBo commented Nov 2, 2021

Uh oh!

davidwrighton commented Nov 2, 2021

Uh oh!

jaredpar commented Nov 2, 2021

Uh oh!

Uh oh!

jkotasNov 2, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

vargazNov 3, 2021

Choose a reason for hiding this comment

Uh oh!

stephentoub commented Nov 30, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

davidwrighton commented Nov 2, 2021•
edited
Loading