Why 16Mib static array size limit?

[Steven Schveighoffer via Digitalmars-d]

On 8/16/16 4:11 PM, Yuxuan Shui wrote:
> On Tuesday, 16 August 2016 at 17:51:13 UTC, Johan Engelen wrote:
>> On Tuesday, 16 August 2016 at 01:28:05 UTC, Ali Çehreli wrote:
>>>
>>> With ldc2, the best option is to go with a dynamic array ONLY IF you
>>> access the elements through the .ptr property. As seen in the last
>>> result, using the [] operator on the array is about 4 times slower
>>> than that.
>>
>> As Yuxuan Shui mentioned the difference is in vectorization. The
>> non-POINTER version is not vectorized because the semantics of the
>> code is not the same as the POINTER version. Indexing `arr`, and
>> writing to that address could change `arr.ptr`, and so the loop would
>> do something different when "caching" `arr.ptr` in `p` (POINTER
>> version) versus the case without caching (non-POINTER version).
>>
>> Evil code demonstrating the problem:
>> ```
>> ubyte evil;
>> ubyte[] arr;
>>
>> void doEvil() {
>>     // TODO: use this in the obfuscated-D contest
>>     arr = (&evil)[0..50];
>> }
>> ```
>>
>> The compiler somehow has to prove that `arr[i]` will never point to
>> `arr.ptr` (it's called Alias Analysis in LLVM).
>>
>> Perhaps it is UB in D to have `arr[i]` ever point into `arr` itself, I
>> don't know. If so, the code is vectorizable and we can try to make it so.
>>
>> -Johan
>
> Wait, doesn't D have strict aliasing rules? ubyte* (&evil) should not be
> allowed to alias with ubyte** (&arr.ptr).

Even if it did, I believe the wildcard is ubyte*. Just like in C, char* 
can point at anything, ubyte is D's equivalent.

-Steve