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

Use a simple temp instead of InlineArray1 #73086

Merged
merged 10 commits into from
May 8, 2024
Original file line number Diff line number Diff line change
Expand Up @@ -439,6 +439,23 @@ private static bool ShouldUseInlineArray(BoundCollectionExpressionBase node, CSh
Debug.Assert(_compilation.Assembly.RuntimeSupportsInlineArrayTypes);

int arrayLength = elements.Length;
if (arrayLength == 1
&& _factory.WellKnownMember(asReadOnlySpan
? WellKnownMember.System_ReadOnlySpan_T__ctor_ref_readonly_T
: WellKnownMember.System_Span_T__ctor_ref_T, isOptional: true) is MethodSymbol spanRefConstructor)
{
// Special case: no need to create an InlineArray1 type. Just use a temp of the element type.
var spanType = _factory
.WellKnownType(asReadOnlySpan ? WellKnownType.System_ReadOnlySpan_T : WellKnownType.System_Span_T)
.Construct([elementType]);
var constructor = spanRefConstructor.AsMember(spanType);
var element = VisitExpression((BoundExpression)elements[0]);
var temp = _factory.StoreToTemp(element, out var assignment);
Copy link
Member

Choose a reason for hiding this comment

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

What is the re-use policies on these temps? Basically is there any chance that the temp slot allocated here will be re-used or is it considered a temp that lives for the lifetime of the current method?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think the local slot can be reused outside the containing block, but that's fine, since the span value that references the temp can't escape outside the containing block.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm. Some of our temp are statement level. I agree block level temp is fine but we should be sure which this is. Had other bugs with statement temps being reused in span before

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added a test. It doesn't look like the temp is reused.

Copy link
Member

Choose a reason for hiding this comment

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

Not sure the test is sufficient here. Looking at the code it seems that it's a re-usable temp. The default kind of the temp is SynthesizedLocalKind.LoweringTemp and that is not a long lived temp. The doc mentions these cannot live across a statement boundary

    /// 1) Short-lived (temporary)
    ///    The lifespan of a temporary variable shall not cross a statement boundary (a PDB sequence point).
    ///    These variables are not tracked by EnC and don't have names. Only values less than 0 are considered
    ///    short-lived: new short-lived kinds should have a negative value.

Copy link
Contributor

Choose a reason for hiding this comment

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

What is the re-use policies on these temps?

Slots can be reused for locals that go out of scope. The scope is defined by blocks and sequences that list locals they own. If I remember correctly, sometimes scope of locals is extended by codegen, when, for example, a sequence returns a ref to a local that it owns. One might say the bound tree violates scoping rules in such cases, but for whatever reason a decision was made to handle the case instead of enforcing correctness of the tree.

That said, symbols for temps are never reused by default. One might, of course, intentionally create a bound tree that shares the same temp for different purposes.

I hope that helps with concerns that prompted the original question.

Copy link
Contributor

Choose a reason for hiding this comment

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

Regarding the short-lived/long-lived story. According to my understanding, these are mostly about PDB/ENC, and the statement boundary the comment is talking about is in terms of syntax (perhaps talking in terms of sequence point boundaries would be more accurate), not about bound statement nodes. Reuse of slots in IL is not based on that. It is based on what I said in the previous message on this thread. So as long as the local is added to the right BoundBlock/BoundSequence, it will not be reused while code for that node is emitted.

There is, however, something interesting going on with where we put inline array locals. The line locals.Add(inlineArrayLocal.LocalSymbol); below. According to comments on _additionalLocals field, the local is going to end up on the enclosing method outermost block. Hopefully that is not going to mess with EnC too much because effectively the local crosses a sequence point boundary. "Collection expressions" devs might want to take a close look at this.

Copy link
Member

Choose a reason for hiding this comment

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

Great. Thansk for the explanation!

Copy link
Member

Choose a reason for hiding this comment

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

There is, however, something interesting going on with where we put inline array locals. ...

Logged #73246 based on this comment and offline discussion.

locals.Add(temp.LocalSymbol);
var call = _factory.New(constructor, arguments: [temp], argumentRefKinds: [asReadOnlySpan ? RefKind.In : RefKind.Ref]);
RikkiGibson marked this conversation as resolved.
Show resolved Hide resolved
return _factory.Sequence([assignment], call);
}

var inlineArrayType = _factory.ModuleBuilderOpt.EnsureInlineArrayTypeExists(syntax, _factory, arrayLength, _diagnostics.DiagnosticBag).Construct(ImmutableArray.Create(elementType));
Debug.Assert(inlineArrayType.HasInlineArrayAttribute(out int inlineArrayLength) && inlineArrayLength == arrayLength);

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -789,6 +789,21 @@ public BoundObjectCreationExpression New(NamedTypeSymbol type, ImmutableArray<Bo
public BoundObjectCreationExpression New(MethodSymbol ctor, ImmutableArray<BoundExpression> args)
=> new BoundObjectCreationExpression(Syntax, ctor, args) { WasCompilerGenerated = true };

public BoundObjectCreationExpression New(MethodSymbol constructor, ImmutableArray<BoundExpression> arguments, ImmutableArray<RefKind> argumentRefKinds)
=> new BoundObjectCreationExpression(
Syntax,
constructor,
arguments,
argumentNamesOpt: default,
argumentRefKinds,
expanded: false,
argsToParamsOpt: default,
defaultArguments: default,
constantValueOpt: null,
initializerExpressionOpt: null,
constructor.ContainingType)
{ WasCompilerGenerated = true };

public BoundObjectCreationExpression New(WellKnownMember wm, ImmutableArray<BoundExpression> args)
{
var ctor = WellKnownMethod(wm);
Expand Down
1,514 changes: 689 additions & 825 deletions src/Compilers/CSharp/Test/Emit2/Semantics/CollectionExpressionTests.cs

Large diffs are not rendered by default.

Original file line number Diff line number Diff line change
Expand Up @@ -4558,9 +4558,7 @@ static void Test(params System.Span<int> a)

CompileAndVerify(
comp,
verify: ExecutionConditionUtil.IsMonoOrCoreClr ?
Verification.FailsILVerify with { ILVerifyMessage = "[InlineArrayAsSpan]: Return type is ByRef, TypedReference, ArgHandle, or ArgIterator. { Offset = 0xc }" }
: Verification.Skipped,
verify: Verification.Skipped,
Copy link
Member

Choose a reason for hiding this comment

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

Curious now. Lets say I have the following code:

M(1);
M(2);
void M(params Span<int> i) { } 

After this change the compiler will optimize the calling code to roughly be:

int tmp = 1;
M(new Span<int>(ref temp));

But do we create 1 or 2 temps here? Guessing we only create one today but want to check. This could be a significant optimization opportunity for us in the future.

expectedOutput: ExpectedOutput(@"
int
int")).VerifyDiagnostics();
Expand Down Expand Up @@ -4598,9 +4596,7 @@ class C3 : C2 {}

CompileAndVerify(
comp,
verify: ExecutionConditionUtil.IsMonoOrCoreClr ?
Verification.FailsILVerify with { ILVerifyMessage = "[InlineArrayAsSpan]: Return type is ByRef, TypedReference, ArgHandle, or ArgIterator. { Offset = 0xc }" }
: Verification.Skipped,
verify: Verification.Skipped,
expectedOutput: ExpectedOutput(@"
C2
C2")).VerifyDiagnostics();
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -1071,6 +1071,8 @@ public void AllWellKnownTypeMembers()
case WellKnownMember.System_Span_T__CopyTo_Span_T:
case WellKnownMember.System_ReadOnlySpan_T__CopyTo_Span_T:
case WellKnownMember.System_Collections_Immutable_ImmutableArray_T__AsSpan:
case WellKnownMember.System_Span_T__ctor_ref_T:
case WellKnownMember.System_ReadOnlySpan_T__ctor_ref_readonly_T:
// Not always available.
continue;
}
Expand Down
2 changes: 2 additions & 0 deletions src/Compilers/Core/Portable/WellKnownMember.cs
Original file line number Diff line number Diff line change
Expand Up @@ -479,13 +479,15 @@ internal enum WellKnownMember

System_Span_T__ctor_Pointer,
System_Span_T__ctor_Array,
System_Span_T__ctor_ref_T,
System_Span_T__get_Item,
System_Span_T__get_Length,
System_Span_T__Slice_Int_Int,

System_ReadOnlySpan_T__ctor_Pointer,
System_ReadOnlySpan_T__ctor_Array,
System_ReadOnlySpan_T__ctor_Array_Start_Length,
System_ReadOnlySpan_T__ctor_ref_readonly_T,
System_ReadOnlySpan_T__get_Item,
System_ReadOnlySpan_T__get_Length,
System_ReadOnlySpan_T__Slice_Int_Int,
Expand Down
18 changes: 18 additions & 0 deletions src/Compilers/Core/Portable/WellKnownMembers.cs
Original file line number Diff line number Diff line change
Expand Up @@ -3333,6 +3333,14 @@ static WellKnownMembers()
1, // Method Signature
(byte)SignatureTypeCode.TypeHandle, (byte)SpecialType.System_Void, // Return Type
(byte)SignatureTypeCode.SZArray, (byte)SignatureTypeCode.GenericTypeParameter, 0,

// System_Span_T__ctor_ref_T
(byte)(MemberFlags.Constructor), // Flags
(byte)WellKnownType.ExtSentinel, (byte)(WellKnownType.System_Span_T - WellKnownType.ExtSentinel), // DeclaringTypeId
0, // Arity
1, // Method Signature
(byte)SignatureTypeCode.TypeHandle, (byte)SpecialType.System_Void, // Return Type
(byte)SignatureTypeCode.ByReference, (byte)SignatureTypeCode.GenericTypeParameter, 0,

// System_Span_T__get_Item
(byte)(MemberFlags.PropertyGet), // Flags
Expand Down Expand Up @@ -3388,6 +3396,14 @@ static WellKnownMembers()
(byte)SignatureTypeCode.TypeHandle, (byte)SpecialType.System_Int32,
(byte)SignatureTypeCode.TypeHandle, (byte)SpecialType.System_Int32,

// System_ReadOnlySpan_T__ctor_ref_readonly_T
(byte)(MemberFlags.Constructor), // Flags
(byte)WellKnownType.ExtSentinel, (byte)(WellKnownType.System_ReadOnlySpan_T - WellKnownType.ExtSentinel), // DeclaringTypeId
0, // Arity
1, // Method Signature
(byte)SignatureTypeCode.TypeHandle, (byte)SpecialType.System_Void, // Return Type
(byte)SignatureTypeCode.ByReference, (byte)SignatureTypeCode.GenericTypeParameter, 0,
Copy link
Member

Choose a reason for hiding this comment

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

The signature of the ReadOnlySpan consructor changed between net7.0 and net8.0 from in to ref readonly. Will this match both versions?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In practice I expect it will. This is because the comparison here is just checking that it is a managed reference according to the runtime. It doesn't check anything about the readability or writability of the reference (C#-level concepts).

However for the particular way this optimization is implemented, I think won't even enter the path for using the 'Span referencing a temp' optimization for net7, because the containing code path is gated on InlineArray runtime feature availability, IIRC. This is shown in the codegen for the tests which use target framework net7.

Copy link
Member

Choose a reason for hiding this comment

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

Yep. I'm less interested in the optimization being applied and more interested in making sure that this well known member can see both variations of the signature. Otherwise it could create confusion for later changes.


// System_ReadOnlySpan_T__get_Item
(byte)(MemberFlags.PropertyGet), // Flags
(byte)WellKnownType.ExtSentinel, (byte)(WellKnownType.System_ReadOnlySpan_T - WellKnownType.ExtSentinel), // DeclaringTypeId
Expand Down Expand Up @@ -4722,12 +4738,14 @@ static WellKnownMembers()
".ctor", // System_Runtime_CompilerServices_ObsoleteAttribute__ctor
".ctor", // System_Span_T__ctor_Pointer
".ctor", // System_Span_T__ctor_Array
".ctor", // System_Span_T__ctor_ref_T
"get_Item", // System_Span_T__get_Item
"get_Length", // System_Span_T__get_Length
"Slice", // System_Span_T__Slice_Int_Int
".ctor", // System_ReadOnlySpan_T__ctor_Pointer
".ctor", // System_ReadOnlySpan_T__ctor_Array
".ctor", // System_ReadOnlySpan_T__ctor_Array_Start_Length
".ctor", // System_ReadOnlySpan_T__ctor_ref_readonly_T
"get_Item", // System_ReadOnlySpan_T__get_Item
"get_Length", // System_ReadOnlySpan_T__get_Length
"Slice", // System_ReadOnlySpan_T__Slice_Int_Int
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -821,7 +821,9 @@ End Namespace
WellKnownMember.System_ReadOnlySpan_T__ToArray,
WellKnownMember.System_Span_T__CopyTo_Span_T,
WellKnownMember.System_ReadOnlySpan_T__CopyTo_Span_T,
WellKnownMember.System_Collections_Immutable_ImmutableArray_T__AsSpan
WellKnownMember.System_Collections_Immutable_ImmutableArray_T__AsSpan,
WellKnownMember.System_Span_T__ctor_ref_T,
WellKnownMember.System_ReadOnlySpan_T__ctor_ref_readonly_T
' Not always available.
Continue For
End Select
Expand Down Expand Up @@ -1026,7 +1028,9 @@ End Namespace
WellKnownMember.System_ReadOnlySpan_T__ToArray,
WellKnownMember.System_Span_T__CopyTo_Span_T,
WellKnownMember.System_ReadOnlySpan_T__CopyTo_Span_T,
WellKnownMember.System_Collections_Immutable_ImmutableArray_T__AsSpan
WellKnownMember.System_Collections_Immutable_ImmutableArray_T__AsSpan,
WellKnownMember.System_Span_T__ctor_ref_T,
WellKnownMember.System_ReadOnlySpan_T__ctor_ref_readonly_T
' Not always available.
Continue For
End Select
Expand Down