-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
CoreCLR support for InlineArrayAttribute. (struct layout part) #82744
Conversation
df38f95
to
6e8c11b
Compare
src/coreclr/tools/Common/TypeSystem/Common/MetadataFieldLayoutAlgorithm.cs
Outdated
Show resolved
Hide resolved
src/coreclr/tools/Common/TypeSystem/Common/MetadataFieldLayoutAlgorithm.cs
Outdated
Show resolved
Hide resolved
I think the PR is ready to be reviewed. |
@davidwrighton as well. |
src/coreclr/inc/corinfo.h
Outdated
@@ -852,7 +852,7 @@ enum CorInfoFlag | |||
CORINFO_FLG_ARRAY = 0x00080000, // class is an array class (initialized differently) | |||
CORINFO_FLG_OVERLAPPING_FIELDS = 0x00100000, // struct or class has fields that overlap (aka union) | |||
CORINFO_FLG_INTERFACE = 0x00200000, // it is an interface | |||
CORINFO_FLG_DONT_DIG_FIELDS = 0x00400000, // don't ask field info, AOT can't rely on it (used for types outside of AOT compilation version bubble) | |||
CORINFO_FLG_DONT_DIG_FIELDS = 0x00400000, // don't ask field info (used for types outside of AOT compilation version bubble and value arrays) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This flag was called CORINFO_FLG_DONT_PROMOTE
at the time of the prototype. We do not want inline arrays to promote as indexing relies on contiguous layout.
I assume the flag still has the effect of suppressing field promotion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should double check with the JIT team - I would think we should be setting similar flags that we set for explicit layout structs and explicit layout structs don't set this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dotnet/jit-contrib can someone from the JIT team take a look at this part?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CORINFO_FLG_DONT_DIG_FIELDS
doesn't always suppress promotion (eg a single gc ref field struct will still get promoted).
I would introduce a new flag describing this, something like CORINFO_FLG_INDEXABLE_FIELDS
, and update the jit to block promotion when it sees it. Looks like there is still one free bit?
Down the road we might be doing more flexible partial promotion and perhaps even handle cases like these where we know exactly which fields are being touched over some span of code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
update the jit to block promotion when it sees it
Is there an easy way to find all the places that need to care about the bit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@VSadov I do think we need a JIT-EE GUID update here -- otherwise it can expose all sorts of latent issues for the JIT team once we get newer collections with this flag that older JITs do not handle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Thanks!! I will change the guid in a follow up change.
In theory the presence of the attribute will imply the new runtime and prevent many versioning issues, but it is better to be sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how hard would it be to begin consuming the support?
Fairly easy. Roslyn will add a layer of convenience, but otherwise the feature can be used directly.
I’ve added some use cases in corlib and libraries as a part of the change.
The only usual caveat with using a feature this early is possibly having to change things if the feature changes based on feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jakobbotsch Sorry, did not notice your yesterdays comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory the presence of the attribute will imply the new runtime and prevent many versioning issues, but it is better to be sure.
The problem for the JIT team is that we disambiguate compatibility of SPMI collections via the JIT-EE GUID. We automatically collect every Sunday, so after that we will start seeing contexts with the new flag set and no indication that newer JITs are needed to properly handle this. That might not cause any problems except silent bad codegen for our SPMI runs, but it could also conceivably cause spurious assertion failures.
FWIW, @EgorBo just merged #83430 which includes a JIT-EE GUID bump, so you won't need to do that in a follow-up change after all.
Fairly easy. Roslyn will add a layer of convenience, but otherwise the feature can be used directly.
I’ve added some use cases in corlib and libraries as a part of the change.
I've looked at some of the examples, that looks fairly straightforward. I guess the main thing is how to get access to InlineArrayAttribute
from the programs I'm generating.
} | ||
else | ||
{ | ||
// TODO: diagnostics, repeat must be > 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want a special diagnostic messages for this or IDS_CLASSLOAD_GENERAL
is good enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The bar for type loader error messages has been:
- Good error message if it is something you can hit by writing C#.
- Generic error message is ok if it is something that can be only hit by writing IL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, made a similar comment above. If there is some likelihood where customers might hit such cases a specific message would be helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good error message if it is something you can hit by writing C#.
Yes, these can be hit, so need specific messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good error message if it is something you can hit by writing C#.
Yes, these can be hit, so need specific messages.
Isn't C# going to have syntax for this? If so, it's likely they're going to prevent people placing this attribute on random stuff like they do for IsByRefLikeAttribute
. Would want to double check, but it's not an unreasonable request to make.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for now we should assume that the attribute is valid for direct use. It is not as dangerous as IsByRefLike
and is relatively easy to use correctly. There could be some use scenarios that are not covered by C# features.
If eventually we see that it is better to disallow, we can do that and make errors less friendly.
I think for the time being, while C# features are in design/prototyping/development, nicer errors would be a good thing.
long size = instanceByteSizeAndAlignment.Size.AsInt; | ||
size *= repeat; | ||
|
||
// limit the max size of array instance to 1MiB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add same limit to the coreclr typeloader as well?
private object? _arg1; | ||
private object? _arg2; | ||
private object? _arg3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
private object? _arg1; | |
private object? _arg2; | |
private object? _arg3; | |
private T _arg1; | |
private T _arg2; | |
private T _arg3; |
?
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
@@ -2,6 +2,7 @@ | |||
// The .NET Foundation licenses this file to you under the MIT license. | |||
|
|||
using System.Collections.Generic; | |||
using System.Diagnostics; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused using?
/// <summary> | ||
/// Gets a value indicating whether this is an inline array type | ||
/// </summary> | ||
public virtual bool IsInlineArray |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be virtual. Things that are computed from flags are determined from flags (and fully inlineable).
@@ -91,6 +91,13 @@ public override bool IsSequentialLayout | |||
} | |||
} | |||
|
|||
public override bool IsInlineArray => Length > 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not convert this to an inline array at this time. I'm concerned we have very little test coverage for this, at least until we can run the src/tests tree. We're not far from being able to do that.
This type is only used in marshalled interop and currently the only test coverage for marshalled interop we have is a smoke test under src/test/nativeaot, because we were very efficient in removing all built-in marshalling use within libraries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. If there is little coverage, there is not a lot of point to make this change right now.
@@ -25,5 +25,11 @@ public partial class InstantiatedType | |||
if (_typeDef.IsIntrinsic) | |||
flags |= TypeFlags.IsIntrinsic; | |||
} | |||
|
|||
partial void AddComputedInlineArrayFlag(ref TypeFlags flags) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically this should go to a new file TypeDesc.Metadata.cs
, but maybe this is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically this should go to a new file TypeDesc.Metadata.cs, but maybe this is fine.
I will not change this part then.
Let me know if you rethink this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jit changes look good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Thanks!! |
Implements support for
InlineArrayAtribute
as in #61135Re: #81145