[clang] [clang][Sema] Avoid out-of-memory crash on huge designated initializer indices (PR #205503)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> There's a significant difference in the actual memory usage in different scenarios.

As an implementation detail of Clang and LLVM, yes, definitely.

>     * An array that's actually zero-initialized takes no memory until runtime (we stick it in bss).
> 
>     * An array that has trailing zeros takes up no memory in the compiler, and space proportional to the runtime size of the array in the object file.
> 
>     * An integer array initialized with #embed uses something like 2-3x the runtime size of the array in the compiler.  We store the initializer in the clang AST, then in LLVM IR, then in the object file.  We can possibly remove one of those copies if we care enough.
> 
>     * An array with leading zeros costs 8 bytes per implicitly initialized element (one pointer per element in the InitListExpr).
> 
>     * If we can't constant-evaluate the initializer (`struct A { A(); A(int); };A x[10] = {[9] = 1};`), implicitly initialized elements become very expensive because we don't emit a loop in LLVM IR.
> 
> 
> It's hard to set good thresholds given the differences. I don't really want to reject `#embed`'ing 1MB files by default.

My point is more: to a user, these are not different at all, and so rejecting one form but not others is a weird inconsistency that's hard to reason about. So to me, I think the better approach is to improve the designated initializer implementation rather than constrain just the designated initializer use, but if that's too hard to solve, we should consistently diagnose based on array size in general rather than implementation behavior of a particular initialization pattern.

> 3. Park this and prototype a sparse or filler representation for leading zeros, which is @erichkeane's idea

This one is my preference as well.


https://github.com/llvm/llvm-project/pull/205503