[PATCH] D155955: [Clang] Improve the handling of large arrays evaluation.

Mon Jul 24 09:32:55 PDT 2023

cor3ntin added a comment.

In D155955#4528571 <https://reviews.llvm.org/D155955#4528571>, @efriedma wrote:

> The UINT_MAX thing seems like a straightforward bug; if we have time to fix it properly, I'd prefer not to add weird workarounds.

Note sure what you mean. Making sure we use `size_t` for all array extents is not something that can be fixed overnight but more importantly, it does not help:
Would it not overflow, the allocation would still fail.

> The release note says "unless they are part of a constant expression", but I don't see any code in the implementation that distinguishes folding from constant expression evaluation.  Unless this is just referring to the fact that bailing out of folding doesn't produce an error?  We might want to consider using a stricter bound for optional folding, though.

I need to update the release notes/commit message they are no reflective of the current design which always look at fconstexpr-steps in all modes of evaluation. It's much cleaner that way.

> How likely is it that we could add some sort of optimization for new expressions so we don't represent each element separately in memory?  I know there's no solution in general, but in the cases people actually care about, all/almost all the elements are identical.

I don't think that would make sense in actual code, and having some sort of sparse array is something I considered. And we already delay allocation in some cases, but we do need to create elements to destroy them, read them, etc. So while it may be possible, it seems... complicated.
I think a more viable long term fix might be to not crash on allocation failure, and/or to have a way to limit the allocation to some portion of the available memory.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155955/new/

https://reviews.llvm.org/D155955