public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: Simplify types of arrays
Date: Thu, 08 Nov 2018 08:01:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.20.1811080858050.1827@zhemvz.fhfr.qr> (raw)
In-Reply-To: <20181107154134.d2iufzncs3reflrd@kam.mff.cuni.cz>

On Wed, 7 Nov 2018, Jan Hubicka wrote:

> Hi,
> this patch simplfies types of arrays so we don't propagate duplicates
> when record/union contains array of pointers.
> With this we still miss simplification of pointers to arrays of
> structures (where we need to rebuild array same way as we rebuild
> pointers) and enumerate types. That should make simplification of types
> complete. Neither of those two seems very critical for GCC build,
> with the patch we are down to 24 duplicated types in bootstrap, I will
> collect data on firefox, but things looks quite good.
> (from tens of thousdant week ago).
> 
> The patch works, but I am somewhat nervous because modyfing type inplace
> affects its type_hash_canon_hash and friends.

Indeed - I don't think we want to do this here and this way.  What
you'd need to do is record uses of a type and replace all uses with
a simplified copy ...

> There are pre-existing
> modifications to function parameters and things seems to just work,
> but I wonder if we have any strategy on keeping hashes in tree.c
> consitent across free-lang data? Or are all those hashes unused/freed at
> this time?

They are not freed and I don't see why they should.

> lto-bootstrapped/regtested x86_64-linux.

Please lets not do this and instead keep the array of pointers
thing in mind.

Does it really matter so much?  That is, where are those arrays
with pointer to complete type referenced from?  Global variables?
As fields in records they are already fixed up properly, right?

Richard.

> Honza
> 
> 	* tree.c (free_lang_data_in_type): Simplify types of arrays.
> Index: tree.c
> ===================================================================
> --- tree.c	(revision 265877)
> +++ tree.c	(working copy)
> @@ -5320,6 +5320,8 @@ free_lang_data_in_type (tree type, struc
>  	  TREE_PURPOSE (p) = NULL;
>  	}
>      }
> +  else if (TREE_CODE (type) == ARRAY_TYPE)
> +    TREE_TYPE (type) = fld_simplified_type (TREE_TYPE (type), fld);
>    else if (RECORD_OR_UNION_TYPE_P (type))
>      {
>        /* Remove members that are not FIELD_DECLs from the field list
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)

  reply	other threads:[~2018-11-08  8:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-07 15:41 Jan Hubicka
2018-11-08  8:01 ` Richard Biener [this message]
2018-11-08 10:55   ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.20.1811080858050.1827@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).