Why 16Mib static array size limit?

[Charles Hixson via Digitalmars-d]

On 08/16/2016 01:49 PM, Steven Schveighoffer via Digitalmars-d wrote:
> 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
>
I think what you say is true (look at the code of std.outbuffer), but 
IIRC the documentation says that's supposed to be the job of void*.