-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[release/7.0-rc2] Do not request type layout for RuntimeDetermined types #75789
[release/7.0-rc2] Do not request type layout for RuntimeDetermined types #75789
Conversation
#74123 broke compiling TechEmpower benchmarks with NativeAOT. We now crash with: ``` > ILCompiler.TypeSystem.dll!Internal.TypeSystem.RuntimeDeterminedFieldLayoutAlgorithm.ComputeInstanceLayout(Internal.TypeSystem.DefType defType, Internal.TypeSystem.InstanceLayoutKind layoutKind) Line 19 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.DefType.ComputeInstanceLayout(Internal.TypeSystem.InstanceLayoutKind layoutKind) Line 436 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.DefType.IsInt128OrHasInt128Fields.get() Line 150 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.MetadataFieldLayoutAlgorithm.ComputeAutoFieldLayout(Internal.TypeSystem.MetadataType type, int numInstanceFields) Line 483 C# ILCompiler.Compiler.dll!ILCompiler.CompilerMetadataFieldLayoutAlgorithm.ComputeInstanceFieldLayout(Internal.TypeSystem.MetadataType type, int numInstanceFields) Line 56 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.MetadataFieldLayoutAlgorithm.ComputeInstanceLayout(Internal.TypeSystem.DefType defType, Internal.TypeSystem.InstanceLayoutKind layoutKind) Line 164 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.DefType.ComputeInstanceLayout(Internal.TypeSystem.InstanceLayoutKind layoutKind) Line 436 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.DefType.InstanceFieldSize.get() Line 165 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.MetadataFieldLayoutAlgorithm.ComputeFieldSizeAndAlignment(Internal.TypeSystem.TypeDesc fieldType, bool hasLayout, int packingSize, out bool layoutAbiStable, out bool fieldTypeHasAutoLayout, out bool fieldTypeHasInt128Field) Line 838 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.MetadataFieldLayoutAlgorithm.ComputeStaticFieldLayout(Internal.TypeSystem.DefType defType, Internal.TypeSystem.StaticLayoutKind layoutKind) Line 215 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.DefType.ComputeStaticFieldLayout(Internal.TypeSystem.StaticLayoutKind layoutKind) Line 473 C# ILCompiler.TypeSystem.dll!Internal.TypeSystem.DefType.GCStaticFieldSize.get() Line 302 C# ILCompiler.Compiler.dll!ILCompiler.DependencyAnalysis.NativeLayoutTemplateTypeLayoutVertexNode.GetStaticDependencies(ILCompiler.DependencyAnalysis.NodeFactory context) Line 997 C# ``` https://github.com/dotnet/runtime/blob/4cf1383c8458945b7eb27ae5f57338c10ed25d54/src/coreclr/tools/Common/TypeSystem/RuntimeDetermined/RuntimeDeterminedFieldLayoutAlgorithm.cs#L17-L19 I was not able to come up with a standalone repro case, but this fixes compiling the benchmark. I'm not clear why native layout operates on runtime determined forms, but what I'm doing here should have equivalent behaviors, except avoiding the problem that we can no longer compute layouts of runtime determined things in some obscure scenarios due to the new code.
@MichalStrehovsky Could you please take care of the servicing bar paperwork? |
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.
approved. we will take for consideration in RC2
Steve signed off on this by email. Should I flip the label to servicing approved? (Or who is supposed to flip the label?) |
CI is green. Approved and signed off. Ready to merge. |
Backport of #75746 to release/7.0-rc2
/cc @jkotas @MichalStrehovsky
Customer Impact
It's not possible to build the TechEmpower benchmarks (or the default MVC Razor template) with NativeAOT because the compiler crashes. See #75746 for stack.
Testing
Verified the benchmark can now be built. Passes all NativeAOT testing we have.
Risk
Low, the fix is relatively conservative and switched from looking at the layout of
RuntimeDetermined
types to__Canon
types (that behave identically as far as layout is concerned). This codepath is exercised pretty extensively. The buggy codepath required some very unique conditions to repro and is specific to layouts of RuntimeDetermined types.