Implement stackalloc initializers #24249

alrz · 2018-01-15T22:29:07Z

stackalloc int[3]				// currently allowed
stackalloc int[3] { 1, 2, 3 }
stackalloc int[] { 1, 2, 3 }
stackalloc[] { 1, 2, 3 }

alrz · 2018-01-15T22:33:56Z

stackalloc[] syntax is undone but I'd appreciate some AOT reviews. Thanks. #Resolved

AlekseyTs · 2018-01-16T19:51:21Z

@alrz Was the proposal approved by the LDM? #Resolved

alrz · 2018-01-16T19:59:57Z

As far as I can tell, the proposal has been approved to merge. though, it's not triaged yet. #Resolved

alrz · 2018-01-21T20:51:23Z

src/Compilers/CSharp/Portable/CodeGen/EmitExpression.cs

+
+                if (expression.InitializerOpt != null)
+                {
+                    EmitStackAllocInitializers(expression.Type, expression.InitializerOpt);


If unused, should still emit init elements to preserve sideeffects

alrz · 2018-01-21T20:52:22Z

src/Compilers/Core/Portable/CodeGen/ILBuilderEmit.cs

+            EmitOpCode(ILOpCode.Ldsflda);
+            EmitToken(field, syntaxNode, diagnostics);
+            EmitIntConstant(data.Length);
+            EmitOpCode(ILOpCode.Cpblk, -3);


Makes sense to emit initblk if all bytes are the same?

Good point.
The only issue could be is if we want to make Span stackalloc` verifiable, but adjusting verification rules. It is not a problem for now anyways.

In reply to: 162825107 [](ancestors = 162825107)

alrz · 2018-01-21T20:53:30Z

src/Compilers/CSharp/Portable/BoundTree/BoundNodes.xml

@@ -1442,9 +1442,17 @@
    <Field Name="Initializers" Type="ImmutableArray&lt;BoundExpression&gt;"/>
  </Node>

+  <Node Name="BoundStackAllocArrayInitialization" Base="BoundExpression">


Can we reuse BoundArrayInitialization?

jcouv · 2018-01-22T16:35:51Z

I don't think this was discussed in LDM. It's not even a championed issue in csharplang yet. Will bring it up for discussion. #Resolved

jaredpar · 2018-01-22T16:45:45Z

@jcouv is correct. This feature hasn't been sanctioned yet.

I think this is something we'd likely need to open a feature branch for. Given the new syntax here there are a number of non-compiler concerns that we'd need to address: intellisense and ENC in particular.

#Resolved

jcouv · 2018-01-24T20:17:17Z

LDM discussed this today and OK'ed the proposal.
We'll want to maintain the quirk with typing var in local declarations with stackalloc:

var x = stackalloc[] { 1, 2, 3 }; // x has type int*, just like var x = stackalloc int[0];
var x = (stackalloc[] { 1, 2, 3 }); // x has type Span<int>, just like var x = (stackalloc int[0]); #Resolved

alrz · 2018-01-25T10:06:54Z

Yeah, that's messy. we could have avoid that with dotnet/csharplang#877, but I guess we have to live with it now -- unless we're willing to take the breaking change. note, the motivating use case remains intact:

// the compiler fails to determine ternary type and tries to convert both operands to the target type
Span<byte> buffer = size < 128 ? stackalloc byte[size] : new byte[size];

except that we won't depend on stackalloc being a direct local init.

@VSadov @jcouv is this something we could do at this point? #Resolved

VSadov · 2018-01-25T15:24:58Z

In the context of ternary stackalloc has natural Span type.
The special case is only for direct local initialization since that existed before. #Resolved

VSadov · 2018-01-25T15:27:34Z

In the given example “Span” could be “var”. #Resolved

alrz · 2018-01-25T21:08:44Z

Correction: (stackalloc int[3]) is not permitted. See #22046 #Resolved

jcouv · 2018-01-30T22:27:49Z

@alrz @VSadov Just a heads up if you are still targeting this feature for C# 7.3, the approximate timeline is end of February to get features completed (including any critical IDE or other blocking issues) and the feature branches merged back into the main branch. #Resolved

VSadov · 2018-01-31T22:57:33Z

src/Compilers/Core/Portable/CodeGen/ILBuilderEmit.cs

@@ -4,6 +4,7 @@
 using System.Collections.Generic;
 using System.Collections.Immutable;
 using System.Diagnostics;
+using System.Linq;


using static System.Linq.ImmutableArrayExtensions

We generally do not want to work with ImmutableArray through regular Linq extensions #Closed

jcouv · 2018-02-07T23:57:28Z

src/Compilers/CSharp/Test/Semantic/Semantics/StackAllocInitializerTests.cs

+    public class StackAllocInitializerTests : CompilingTestBase
+    {
+        [Fact]
+        public void NoBestType()


I see tests that have a best type which is managed. Can we also cover the case where the best type is void? #Closed

jcouv · 2018-02-07T23:59:43Z

src/Compilers/CSharp/Portable/CodeGen/EmitExpression.cs

+                }
+                else
+                {
+                    // If not used, just emit initializer elements to preserve possible sideeffects


~~Could you point me to the test that covers that? I'm not sure how to hit this.~~
Never mind, found it (TestUnused) #Resolved

jcouv · 2018-02-08T00:03:19Z

src/Compilers/CSharp/Test/Emit/CodeGen/StackAllocInitializerTests.cs

+    }
+}
+";
+            CompileAndVerify(text,


Please also verify execution order with expectedOutput: and printing inside Method and some other method. #Closed

jcouv

Done with review pass. A few test suggestions.
I would take a look a unifying syntax nodes and unifying binding logic, to see if that does make the code better.

alrz · 2018-02-08T07:59:31Z

the blob/cpblk optimization will need to be constrained to happen only when dealing with byte-sized elements.

@VSadov Does this apply to initblk as well?

VSadov · 2018-02-08T17:48:22Z

@alrz - initblk is ok regardless of the element size.

alrz · 2018-02-08T17:54:46Z

initblk is ok regardless of the element size.

Do I need to cover that case in the current PR? that would need GetDataRaw to be called early in ShouldEmitBlockInitializerForStackAlloc which in turn would require a different ArrayInitializerStyle

VSadov · 2018-02-08T18:08:19Z

@alrz - I think we should drive this PR to completion and then do directed PRs that address specific issues.

It may also be acceptable to restrict initblk to the same criteria as cpyblk. Not because it is unsafe to do, but just out of convenience.
Considering that stackalloc zero-initializes by default, initblk case might not be such a common scenario. In fact when we can be sure that localsinit flag is set on the method, it might be easier to just drop the zero-out initializer since JIT zeroinits anyways.

Anyways, it feels like addressing this issue of when and what optimization happens would be easier in a separate PR.

alrz · 2018-02-08T20:04:45Z

@jcouv I've addressed all comments. Not sure about symbol tests, please take look if it covers what you had in mind.

alrz · 2018-02-08T20:07:10Z

Considering that stackalloc zero-initializes by default,

You mean only after #23951, right? last time I checked it was not zero-initialized.

jcouv

One nit and two small test adjustments, then looks good to me. Thanks!

alrz · 2018-02-08T22:03:39Z

testing GetTypeInfo directly on the syntax of the stackalloc.

also test this when the type isn't bound

I think both are addressed now. Note that we call GetSemanticInfoSummary on the direct syntax of the stackalloc.

jcouv

LGTM

VSadov · 2018-02-08T23:22:47Z

Thanks!!

VSadov · 2018-02-08T23:42:10Z

Now it makes sense to tune when optimizations happen.

The idea is that

cpblk can only be used when element is byte-sized (because of bigendian case that is blocked on new API)
initblk does not have the same constraints as cpblk
all-zero initialization does not need to be emitted at all when "initlocals" flag is definitely set. However until https://github.com/dotnet/roslyn/tree/features/localsinit merges, this criteria is not well defined. Most of the times the flag is set, but sometimes it is not set in small methods due to bugs like Compiler should emit localinits when method body contains stackalloc #23951. For now let's not do the skipping.

alrz requested a review from a team as a code owner January 15, 2018 22:29

This was referenced Jan 15, 2018

Extend eligible params types to array generic interfaces and span #24080

Closed

Feature suggestion: zero-allocation "params" via Span<T> / ReadOnlySpan<T> dotnet/csharplang#535

Closed

alrz commented Jan 22, 2018

View reviewed changes

alrz force-pushed the features/stackalloc-init branch from cad1920 to ebc2cd1 Compare January 26, 2018 00:09

Implement stackalloc initializers

9c31503

alrz force-pushed the features/stackalloc-init branch from ebc2cd1 to 9c31503 Compare January 26, 2018 00:18

alrz added 2 commits January 26, 2018 03:49

Update resources

1ff896d

Address test failures

edc09fc

alrz force-pushed the features/stackalloc-init branch from 396214b to edc09fc Compare January 26, 2018 08:29

jcouv mentioned this pull request Jan 29, 2018

Champion: Stackalloc array initializers (15.7) dotnet/csharplang#1286

Open

5 tasks

jcouv added this to the 15.7 milestone Jan 30, 2018

jcouv added Area-Compilers Community The pull request was submitted by a contributor who is not a Microsoft employee. labels Jan 30, 2018

Visit initializer elements in flow analysis

cf00fbe

jcouv assigned VSadov Jan 31, 2018

VSadov reviewed Jan 31, 2018

View reviewed changes

jcouv reviewed Feb 7, 2018

View reviewed changes

jcouv reviewed Feb 8, 2018

View reviewed changes

alrz added 8 commits February 8, 2018 08:54

Revert code.

7ff7236

Add parsing test for bad implicit stackalloc

facb834

Test stackalloc in catch and finally

f95fb81

Whitespaces.

6584454

Add more best type tests

974ee8b

Verify execution order

dde9175

Assert symbols

1eb9599

Emit element-wise assignments for anything larger than byte

b2a28eb

jcouv reviewed Feb 8, 2018

View reviewed changes

alrz added 4 commits February 9, 2018 00:57

Revert code.

c13dd3a

Clean up.

9c5a72e

Add braces.

442c0d7

Assert symbol from syntax

779ff18

jcouv approved these changes Feb 8, 2018

View reviewed changes

VSadov merged commit 916304f into dotnet:features/stackalloc-init Feb 8, 2018

alrz deleted the features/stackalloc-init branch March 13, 2018 17:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement stackalloc initializers #24249

Implement stackalloc initializers #24249

alrz commented Jan 15, 2018 •

edited

Loading

alrz commented Jan 15, 2018 •

edited by jcouv

Loading

AlekseyTs commented Jan 16, 2018 •

edited by jcouv

Loading

alrz commented Jan 16, 2018 •

edited by jcouv

Loading

alrz Jan 21, 2018

alrz Jan 21, 2018

VSadov Jan 31, 2018

alrz Jan 21, 2018

jcouv commented Jan 22, 2018 •

edited

Loading

jaredpar commented Jan 22, 2018 •

edited by jcouv

Loading

jcouv commented Jan 24, 2018 •

edited

Loading

alrz commented Jan 25, 2018 •

edited by jcouv

Loading

VSadov commented Jan 25, 2018 •

edited by jcouv

Loading

VSadov commented Jan 25, 2018 •

edited by jcouv

Loading

alrz commented Jan 25, 2018 •

edited by jcouv

Loading

jcouv commented Jan 30, 2018 •

edited

Loading

VSadov Jan 31, 2018 •

edited

Loading

jcouv Feb 7, 2018 •

edited

Loading

jcouv Feb 7, 2018 •

edited

Loading

jcouv Feb 8, 2018 •

edited

Loading

jcouv left a comment

alrz commented Feb 8, 2018

VSadov commented Feb 8, 2018

alrz commented Feb 8, 2018

VSadov commented Feb 8, 2018

alrz commented Feb 8, 2018

alrz commented Feb 8, 2018

jcouv left a comment

alrz commented Feb 8, 2018 •

edited

Loading

jcouv left a comment

VSadov commented Feb 8, 2018

VSadov commented Feb 8, 2018

Implement stackalloc initializers #24249

Implement stackalloc initializers #24249

Conversation

alrz commented Jan 15, 2018 • edited Loading

alrz commented Jan 15, 2018 • edited by jcouv Loading

AlekseyTs commented Jan 16, 2018 • edited by jcouv Loading

alrz commented Jan 16, 2018 • edited by jcouv Loading

alrz Jan 21, 2018

Choose a reason for hiding this comment

alrz Jan 21, 2018

Choose a reason for hiding this comment

VSadov Jan 31, 2018

Choose a reason for hiding this comment

alrz Jan 21, 2018

Choose a reason for hiding this comment

jcouv commented Jan 22, 2018 • edited Loading

jaredpar commented Jan 22, 2018 • edited by jcouv Loading

jcouv commented Jan 24, 2018 • edited Loading

alrz commented Jan 25, 2018 • edited by jcouv Loading

VSadov commented Jan 25, 2018 • edited by jcouv Loading

VSadov commented Jan 25, 2018 • edited by jcouv Loading

alrz commented Jan 25, 2018 • edited by jcouv Loading

jcouv commented Jan 30, 2018 • edited Loading

VSadov Jan 31, 2018 • edited Loading

Choose a reason for hiding this comment

jcouv Feb 7, 2018 • edited Loading

Choose a reason for hiding this comment

jcouv Feb 7, 2018 • edited Loading

Choose a reason for hiding this comment

jcouv Feb 8, 2018 • edited Loading

Choose a reason for hiding this comment

jcouv left a comment

Choose a reason for hiding this comment

alrz commented Feb 8, 2018

VSadov commented Feb 8, 2018

alrz commented Feb 8, 2018

VSadov commented Feb 8, 2018

alrz commented Feb 8, 2018

alrz commented Feb 8, 2018

jcouv left a comment

Choose a reason for hiding this comment

alrz commented Feb 8, 2018 • edited Loading

jcouv left a comment

Choose a reason for hiding this comment

VSadov commented Feb 8, 2018

VSadov commented Feb 8, 2018

alrz commented Jan 15, 2018 •

edited

Loading

alrz commented Jan 15, 2018 •

edited by jcouv

Loading

AlekseyTs commented Jan 16, 2018 •

edited by jcouv

Loading

alrz commented Jan 16, 2018 •

edited by jcouv

Loading

jcouv commented Jan 22, 2018 •

edited

Loading

jaredpar commented Jan 22, 2018 •

edited by jcouv

Loading

jcouv commented Jan 24, 2018 •

edited

Loading

alrz commented Jan 25, 2018 •

edited by jcouv

Loading

VSadov commented Jan 25, 2018 •

edited by jcouv

Loading

VSadov commented Jan 25, 2018 •

edited by jcouv

Loading

alrz commented Jan 25, 2018 •

edited by jcouv

Loading

jcouv commented Jan 30, 2018 •

edited

Loading

VSadov Jan 31, 2018 •

edited

Loading

jcouv Feb 7, 2018 •

edited

Loading

jcouv Feb 7, 2018 •

edited

Loading

jcouv Feb 8, 2018 •

edited

Loading

alrz commented Feb 8, 2018 •

edited

Loading