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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
