https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
--- Comment #73 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 1 Mar 2019, jakub at gcc dot gnu.org wrote: > 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. Yes, we'd usually not end up with a single NATIVE_ENCODE_RANGE_EXPR but we need to create that "block-wise" to have any savings. IIRC part of the reason for the bloat was that we require constructor indices to be present even for contiguous elements which means having INTEGER_CSTs counting from zero to very large. IIRC I had some partial patches that tried to delay actual constructor element creation for contiguous elements but somehow it didn't work out - and it would break (not save anything) once you start using designated initializers...
