public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Jeff Law <jeffreyalaw@gmail.com>,
	Andrew Pinski <apinski@marvell.com>,
	 Patrick Palka <ppalka@redhat.com>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] tree: Fix up tree_code_{length,type}
Date: Fri, 27 Jan 2023 07:42:39 +0000 (UTC)	[thread overview]
Message-ID: <nycvar.YFH.7.77.849.2301270739220.6551@jbgna.fhfr.qr> (raw)
In-Reply-To: <Y9KjbJA8HZs3nLNX@tucnak>

On Thu, 26 Jan 2023, Jakub Jelinek wrote:

> On Thu, Jan 26, 2023 at 09:45:35AM -0500, Patrick Palka via Gcc-patches wrote:
> > > +#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
> > > +#define END_OF_BASE_TREE_CODES tcc_exceptional,
> > > +
> > > +
> > >  /* Class of tree given its code.  */
> > > -extern const enum tree_code_class tree_code_type[];
> > > +constexpr enum tree_code_class tree_code_type[] = {
> > > +#include "all-tree.def"
> > > +};
> > > +
> > > +#undef DEFTREECODE
> > > +#undef END_OF_BASE_TREE_CODES
> > >  
> > >  /* Each tree code class has an associated string representation.
> > >     These must correspond to the tree_code_class entries.  */
> > >  extern const char *const tree_code_class_strings[];
> > >  
> > >  /* Number of argument-words in each kind of tree-node.  */
> > > -extern const unsigned char tree_code_length[];
> > > +
> > > +#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
> > > +#define END_OF_BASE_TREE_CODES 0,
> > > +constexpr unsigned char tree_code_length[] = {
> > > +#include "all-tree.def"
> > > +};
> > > +
> > > +#undef DEFTREECODE
> > > +#undef END_OF_BASE_TREE_CODES
> > 
> > IIUC defining these globals as non-inline constexpr gives them internal
> > linkage, and so each TU contains its own unique copy of these globals.
> > This bloats cc1plus by a tiny bit and is technically an ODR violation
> > because some inline functions such as tree_class_check also ODR-use
> > these variables and so each defn of tree_class_check will refer to a
> > "different" tree_code_class.  Since inline variables are a C++17
> > feature, I guess we could fix this by defining the globals the old way
> > before C++17 and as inline constexpr otherwise?
> 
> And I'd argue with the tiny bit.
> In my x86_64-linux cc1plus from today, I see 193 _ZL16tree_code_length vars,
> 374 bytes each, and 324 _ZL14tree_code_type vars, 1496 bytes each.
> So, that means waste of 555016 .rodata bytes, plus being highly non-cache
> friendly.
> 
> The following patch does that.
> 
> So far tested on x86_64-linux in my -O0 working tree (system gcc 12
> compiler) where .rodata shrunk with the patch by 928896 bytes, in last
> stage of a bootstrapped tree (built by today's prev-gcc) where .rodata
> shrunk by 561728 bytes (in neither case .text or most other sections
> changed sizes) and on powerpc64le-linux --disable-bootstrap
> (system gcc 4.8.5) to test also the non-C++17 case.
> 
> Ok for trunk if it passes full bootstrap/regtest?
> 
> BTW, wonder if tree_code_type couldn't be an array of unsigned char
> elements rather than enum tree_code_class and we'd then cast it
> to the enum in the macro, that would shrink that array from 1496 bytes
> to 374.  Of course, that sounds like stage1 material.

One could argue the same way for this patch (and instead revert),
I'd say if we tweak this now then tweak it to the maximum extent?
Isn't sth like 'enum unsigned char tree_code_class' now possible?
(and a static assert the enum values all fit, though that would
be diagnosed anyway?)

> 2023-01-26  Patrick Palka  <ppalka@redhat.com>
> 	    Jakub Jelinek  <jakub@redhat.com>
> 
> 	* tree-core.h (tree_code_type, tree_code_length): For
> 	C++17 and later, add inline keyword, otherwise don't define
> 	the arrays, but declare extern arrays.
> 	* tree.cc (tree_code_type, tree_code_length): Define these
> 	arrays for C++14 and older.
> 
> --- gcc/tree-core.h.jj	2023-01-02 09:32:31.188158094 +0100
> +++ gcc/tree-core.h	2023-01-26 16:02:34.212113251 +0100
> @@ -2284,17 +2284,20 @@ struct floatn_type_info {
>  /* Matrix describing the structures contained in a given tree code.  */
>  extern bool tree_contains_struct[MAX_TREE_CODES][64];
>  
> +/* Class of tree given its code.  */
> +#if __cpp_inline_variables >= 201606L
>  #define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
>  #define END_OF_BASE_TREE_CODES tcc_exceptional,
>  
> -
> -/* Class of tree given its code.  */
> -constexpr enum tree_code_class tree_code_type[] = {
> +constexpr inline enum tree_code_class tree_code_type[] = {
>  #include "all-tree.def"
>  };

Do we need an explicit external definition somewhere when
constant folding isn't possible?

Otherwise looks good to me.

Thanks,
Richard.

>  #undef DEFTREECODE
>  #undef END_OF_BASE_TREE_CODES
> +#else
> +extern const enum tree_code_class tree_code_type[];
> +#endif
>  
>  /* Each tree code class has an associated string representation.
>     These must correspond to the tree_code_class entries.  */
> @@ -2302,14 +2305,18 @@ extern const char *const tree_code_class
>  
>  /* Number of argument-words in each kind of tree-node.  */
>  
> +#if __cpp_inline_variables >= 201606L
>  #define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
>  #define END_OF_BASE_TREE_CODES 0,
> -constexpr unsigned char tree_code_length[] = {
> +constexpr inline unsigned char tree_code_length[] = {
>  #include "all-tree.def"
>  };
>  
>  #undef DEFTREECODE
>  #undef END_OF_BASE_TREE_CODES
> +#else
> +extern const unsigned char tree_code_length[];
> +#endif
>  
>  /* Vector of all alias pairs for global symbols.  */
>  extern GTY(()) vec<alias_pair, va_gc> *alias_pairs;
> --- gcc/tree.cc.jj	2023-01-13 17:37:45.259482663 +0100
> +++ gcc/tree.cc	2023-01-26 16:03:59.796878082 +0100
> @@ -74,7 +74,33 @@ along with GCC; see the file COPYING3.
>  #include "asan.h"
>  #include "ubsan.h"
>  
> +#if __cpp_inline_variables < 201606L
> +/* Tree code classes.  */
>  
> +#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
> +#define END_OF_BASE_TREE_CODES tcc_exceptional,
> +
> +const enum tree_code_class tree_code_type[] = {
> +#include "all-tree.def"
> +};
> +
> +#undef DEFTREECODE
> +#undef END_OF_BASE_TREE_CODES
> +
> +/* Table indexed by tree code giving number of expression
> +   operands beyond the fixed part of the node structure.
> +   Not used for types or decls.  */
> +
> +#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) LENGTH,
> +#define END_OF_BASE_TREE_CODES 0,
> +
> +const unsigned char tree_code_length[] = {
> +#include "all-tree.def"
> +};
> +
> +#undef DEFTREECODE
> +#undef END_OF_BASE_TREE_CODES
> +#endif
>  
>  /* Names of tree components.
>     Used for printing out the tree and error messages.  */
> 
> 	Jakub
> 
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

  parent reply	other threads:[~2023-01-27  7:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-18 18:05 [PATCH] constexprify some tree variables apinski
2022-11-18 20:06 ` Jeff Law
2022-11-19  2:53   ` Andrew Pinski
2022-11-19 16:33     ` Jeff Law
2023-01-26 14:45 ` Patrick Palka
2023-01-26 14:51   ` Jakub Jelinek
2023-01-26 14:58     ` Jakub Jelinek
2023-01-26 15:59   ` [PATCH] tree: Fix up tree_code_{length,type} Jakub Jelinek
2023-01-26 18:03     ` Patrick Palka
2023-01-27 12:40       ` Patrick Palka
2023-01-27 13:14         ` Richard Biener
2023-01-27  7:42     ` Richard Biener [this message]
2023-01-27  8:57       ` Jakub Jelinek
2023-01-27  9:49         ` Richard Biener
2023-01-27 20:44 Maciej Cencora

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=nycvar.YFH.7.77.849.2301270739220.6551@jbgna.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=apinski@marvell.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=ppalka@redhat.com \
    /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).