* [PATCH] Use RANGE_EXPR in Fortran array initializers some more (PR fortran/43210)
@ 2019-02-25 23:41 Jakub Jelinek
2019-02-26 9:17 ` Paul Richard Thomas
0 siblings, 1 reply; 3+ messages in thread
From: Jakub Jelinek @ 2019-02-25 23:41 UTC (permalink / raw)
To: fortran; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Use RANGE_EXPR in Fortran array initializers some more (PR fortran/43210)
2019-02-25 23:41 [PATCH] Use RANGE_EXPR in Fortran array initializers some more (PR fortran/43210) Jakub Jelinek
@ 2019-02-26 9:17 ` Paul Richard Thomas
2019-02-26 10:45 ` Jakub Jelinek
0 siblings, 1 reply; 3+ messages in thread
From: Paul Richard Thomas @ 2019-02-26 9:17 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: fortran, gcc-patches
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
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Use RANGE_EXPR in Fortran array initializers some more (PR fortran/43210)
2019-02-26 9:17 ` Paul Richard Thomas
@ 2019-02-26 10:45 ` Jakub Jelinek
0 siblings, 0 replies; 3+ messages in thread
From: Jakub Jelinek @ 2019-02-26 10:45 UTC (permalink / raw)
To: Paul Richard Thomas; +Cc: fortran, gcc-patches
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-02-26 10:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-25 23:41 [PATCH] Use RANGE_EXPR in Fortran array initializers some more (PR fortran/43210) Jakub Jelinek
2019-02-26 9:17 ` Paul Richard Thomas
2019-02-26 10:45 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).