https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Would
--- gcc/tree.def.jj 2025-01-15 08:43:39.818915636 +0100
+++ gcc/tree.def 2025-03-11 23:42:20.672722008 +0100
@@ -505,6 +505,12 @@ DEFTREECODE (OBJ_TYPE_REF, "obj_type_ref
one for each index in the range. (If the corresponding field VALUE
has side-effects, they are evaluated once for each element. Wrap the
value in a SAVE_EXPR if you want to evaluate side effects only once.)
+ If the index is INTEGER_CST and value RAW_DATA_CST, it is a short-hand
+ for RAW_DATA_LENGTH consecutive nodes, first at the given index, each
+ node being build_int_cst (TREE_TYPE (value), TYPE_UNSIGNED (TREE_TYPE
+ (value)) ? (HOST_WIDE_INT) RAW_DATA_UCHAR_ELT (value, n)
+ : (HOST_WIDE_INT) RAW_DATA_SCHAR_ELT (value, n)) at index
+ tree_to_uhwi (index) + n for n from 0 to RAW_DATA_LENGTH (value) - 1.
Components that aren't present are cleared as per the C semantics,
unless the CONSTRUCTOR_NO_CLEARING flag is set, in which case their
clarify this enough?
We have other special cases, an array initializer can be STRING_CST and that is
also a shorthand for initializing all the array elements. RAW_DATA_CST is an
extension from that, allows representing that way only parts of the
initializer, not the whole one,
and doesn't own its data, so it can be cheaply split.
Note, unless you really need to do all the build_int_cst calls for some reason,
it is obviously preferable not to do that, the point of using RAW_DATA_CST
is to save memory and when one builds all the values and even worse all the
indexes,
all those memory savings are gone. Converting can be done here and there for
small amounts of data, e.g. to print something etc., but better should be
avoided doing that on megabytes or gigabytes.
The design is that there could be up to 2GB of data in each RAW_DATA_CST and
say one initializer could have several of them, something that would have no
chance of being compiled without this.
See
https://developers.redhat.com/articles/2025/01/30/how-implement-c23-embed-gcc-15
for some extra details.
