https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
--- Comment #72 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #71)
> (In reply to Frank Ch. Eigler from comment #70)
> > > We could add a NATIVE_ENCODE_RANGE_EXPR that encodes a contiguous range of
> > > bytes in native target representation. Of course that has to be kept
> > > throughout GIMPLE.
> >
> > (Just a silly spitballing here ... but if such a native target
> > representation is
> > not processed again before being sent to the assembler, it could even be
> > stored compressed.)
>
> One step at a time - but sure. Note that we _do_ inspect the data for
> constant folding so whether to compress needs to be evaluated on a
> case-by-case
> basis (only initializers to non-constant objects for example?)
For anything we need to be able to access it easily, say if you have
int a[2][100000000] = { { huge NATIVE_ENCODE_RANGE_EXPR initializer here },
[0][42] = 42 };
For the non-compressed target dependent initializer we actually have a tree
already, STRING_CST, and we actually since PR71625 use it for char/signed
char/unsigned char array initializers, but decide to use it and convert to it
only after the initializer parsing is done, while to avoid using lots of memory
we'd need to decide for that already during parsing, say after parsing a couple
hundreds or thousands elements. And we might consider using it for other types
as well and just natively encode/decode stuff from/to the STRING_CST as needed.
