| Message ID | 20190225230246.GC7611@tucnak |
|---|---|
| State | New |
| Headers | show |
| Series | Use RANGE_EXPR in Fortran array initializers some more (PR fortran/43210) | expand |
Hi Jakub, Your timing is astonishing. This was next on my list of TODOs - not for this particular PR but to deal with the rodata bloat eg. 84487. I presume that this patch will make the latter go away? Yes, this is good for trunk and, if it fixes 84487, 8-branch as well. Thanks Paul On Mon, 25 Feb 2019 at 23:02, Jakub Jelinek <jakub@redhat.com> wrote: > > Hi! > > When initializing whole array with a const, we can save quite some compile > time memory (and time in some cases) by using RANGE_EXPRs, instead of > duplicating the same initializer thousands of times in the CONSTRUCTOR. > In some cases the gimplifier even can optimize those better. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2019-02-25 Jakub Jelinek <jakub@redhat.com> > > PR fortran/43210 > * trans-array.c (gfc_conv_array_initializer): Use RANGE_EXPR instead > of duplicating the initializer possibly many times. > > --- gcc/fortran/trans-array.c.jj 2019-02-10 12:05:42.753718023 +0100 > +++ gcc/fortran/trans-array.c 2019-02-25 18:11:44.948166509 +0100 > @@ -5986,7 +5986,6 @@ gfc_conv_array_initializer (tree type, g > { > gfc_constructor *c; > tree tmp; > - offset_int wtmp; > gfc_se se; > tree index, range; > vec<constructor_elt, va_gc> *v = NULL; > @@ -6009,13 +6008,10 @@ gfc_conv_array_initializer (tree type, g > else > gfc_conv_structure (&se, expr, 1); > > - wtmp = wi::to_offset (TYPE_MAX_VALUE (TYPE_DOMAIN (type))) + 1; > - /* This will probably eat buckets of memory for large arrays. */ > - while (wtmp != 0) > - { > - CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, se.expr); > - wtmp -= 1; > - } > + CONSTRUCTOR_APPEND_ELT (v, build2 (RANGE_EXPR, gfc_array_index_type, > + TYPE_MIN_VALUE (TYPE_DOMAIN (type)), > + TYPE_MAX_VALUE (TYPE_DOMAIN (type))), > + se.expr); > break; > > case EXPR_ARRAY: > > Jakub
On Tue, Feb 26, 2019 at 08:37:28AM +0000, Paul Richard Thomas wrote: > Your timing is astonishing. This was next on my list of TODOs - not > for this particular PR but to deal with the rodata bloat eg. 84487. I > presume that this patch will make the latter go away? > > Yes, this is good for trunk and, if it fixes 84487, 8-branch as well. The patch doesn't change anything on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487#c4 It is really mostly about compile time memory. If a data section variable is initialized with such initializer, it makes no difference in what is emitted. The only difference is that it is more efficient in the compiler to handle such initializer if it is large, and if an automatic variable is ininitialized from such CONSTRUCTOR, the gimplifier can decide to initialize at runtime using a loop or loops rather than using memcpy from a large .rodata initializer. Jakub
--- gcc/fortran/trans-array.c.jj 2019-02-10 12:05:42.753718023 +0100 +++ gcc/fortran/trans-array.c 2019-02-25 18:11:44.948166509 +0100 @@ -5986,7 +5986,6 @@ gfc_conv_array_initializer (tree type, g { gfc_constructor *c; tree tmp; - offset_int wtmp; gfc_se se; tree index, range; vec<constructor_elt, va_gc> *v = NULL; @@ -6009,13 +6008,10 @@ gfc_conv_array_initializer (tree type, g else gfc_conv_structure (&se, expr, 1); - wtmp = wi::to_offset (TYPE_MAX_VALUE (TYPE_DOMAIN (type))) + 1; - /* This will probably eat buckets of memory for large arrays. */ - while (wtmp != 0) - { - CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, se.expr); - wtmp -= 1; - } + CONSTRUCTOR_APPEND_ELT (v, build2 (RANGE_EXPR, gfc_array_index_type, + TYPE_MIN_VALUE (TYPE_DOMAIN (type)), + TYPE_MAX_VALUE (TYPE_DOMAIN (type))), + se.expr); break; case EXPR_ARRAY: