Description

Dereferencing a pointer to a span seems to be unoptimised, see the codegen for M2 vs M1 https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBDAzgWwB8ABAJgEYBYAKGIAYACY8gOgCUBXAOwwEt8YLAJI8YUCAAcAymIBuvMDFwBuGjWIBmBt1zYAZjCakGAYRoBvGg2tMtzJAykTsXADy8eAPgYBZcgAonF3cvACoGbABKKxtLahsEpgB2Xxh8aABPH2woXAALbAAbFhNYbAwYIK5/WD1U9KgsnPyilgBxGAw2GANYLkV/UKi0CLhPABkYLgBzDDzI1XibAF8Y600mcgcqkIxvH1JA5zcPPfCotYY4xJtiFKHFhNXqZ6A=== (thanks @tannergooding for this code, it was not obvious to me this would result in better codegen)

Clearly, it could be theoretically as good as M1 since they do the same thing, but it's not.

There are valid reasons for taking a pointer to a span (and other ref structs), e.g. calling string.Create with some span data, since it can't be used as the TState generic parameter, the only real choice is to pass it by pointer or to copy the data (which is obviously much slower).

Regression?

No afaik

Analysis

I've been informed that the call 0x00007ffaff64e850 (address may vary) is a write barrier (thanks @SingleAccretion).

Apparently this is a known issue, but there is no open issue for it.

The same poor codegen doesn't seem to exist for reference types and normal value types: https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBDAzgWwB8ABAJgEYBYAKBuIGYACAVwDtdsAzGRsxgYRoBvGozG8mxckkYBlAA7ZWAHgCWrDAD5GAWXIAKAEoxsAEwDyrADYBPBUrUbt2AJSjxI6uO+8A7IwAqfXsVdS0AlwAybABudzEAX3iJXmlUgAZdUn0IYAArGDAMRldkzx9xYn8gqXSI6LivcSSmsQZUmWYw3Xp9btLWxnKKv0D9Lo162OSWlqA=== and https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBDAzgWwB8ABAJgEYBYAKBuIGYACAVwDtdsAzGRsxgYRoBvGozG8mxckkYBlAA7ZWAHgCWrDAD5GAWXIAKBUrUbNAKkbYAlKPEjq4x7wDsjM9gDctsQF9vE3mlGCGAAKxgwDF1SfRDwyItrf3sncWJXdy8HcT9ssQZAmWZ1KJ16fWKNRJs8xhTUlzdPf1zcoA===