public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: Richard Biener <rguenther@suse.de>, <gcc-patches@gcc.gnu.org>,
	<pan2.li@intel.com>,
	Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>,
	"Jakub Jelinek" <jakub@redhat.com>
Cc: Kito Cheng <kito.cheng@sifive.com>, <juzhe.zhong@rivai.ai>,
	<yanzhang.wang@intel.com>, <jeffreyalaw@gmail.com>,
	<richard.sandiford@arm.com>
Subject: Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 bits" (was: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits)
Date: Fri, 30 Jun 2023 13:46:07 +0200	[thread overview]
Message-ID: <87o7kxuq9s.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <CALLt3TiCbguYiZhrYLGtMCdT9d_-TsWKiT777qU1D4imqedWFw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

Hi!

On 2023-05-13T16:44:41+0800, Kito Cheng via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> Tried this patch and I ran into some issues, some variables are using
> unsigned char to hold machine mode and will have problems when the
> number of modes is larger than 255...
>
> And here is the fix:

> --- a/gcc/genmodes.cc
> +++ b/gcc/genmodes.cc
> @@ -1141,10 +1141,10 @@ inline __attribute__((__always_inline__))\n\
> #else\n\
> extern __inline__ __attribute__((__always_inline__, __gnu_inline__))\n\
> #endif\n\
> -unsigned char\n\
> +unsigned short\n\
> mode_inner_inline (machine_mode mode)\n\
> {\n\
> -  extern const unsigned char mode_inner[NUM_MACHINE_MODES];\n\
> +  extern const unsigned short mode_inner[NUM_MACHINE_MODES];\n\
>   gcc_assert (mode >= 0 && mode < NUM_MACHINE_MODES);\n\
>   switch (mode)\n\
>     {");
> @@ -1529,7 +1529,7 @@ emit_mode_wider (void)
>   int c;
>   struct mode_data *m;
>
> -  print_decl ("unsigned char", "mode_next", "NUM_MACHINE_MODES");
> +  print_decl ("unsigned short", "mode_next", "NUM_MACHINE_MODES");

Etc.

Instead of 's%char%short', shouldn't we really be using
'enum machine_mode' here?  (I understand such a change may require some
further surgery, but wouldn't it be the correct thing to do?)


And, in context of working on
<https://inbox.sourceware.org/87mt0hcp12.fsf@euler.schwinge.homeip.net>
"Streamer: Fix out of range memory access of machine mode", I found
another one, see attached
'[WIP] Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 bits"'
(..., which applies on top of the former.)  There, in fact, I did change
to 'enum machine_mode' instead of 's%char%short' -- correct?  Any
comments on the 'GTY' issues: (1) 'const' build error,
(2) '[build-gcc]/gcc/gtype-desc.cc' changes, and (3) is 'GTY((atomic))'
actually the right thing to use, here?

In particular, the 'lto_mode_identity_table' changes would seem necessary
to keep standard LTO ('-flto') functional for large 'machine_mode' size?


Bernhard: Fancy writing a Coccinelle check whether there are any more
places where we put what originally was a 'machine_mode' type into a
'char' (or, into a non-'machine_mode' generally)?  ;-) Hey, just a Friday
afternoon idea!


Grüße
 Thomas


-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-WIP-Adjust-LTO-mode-tables-for-Machine_Mode-Extend-m.patch --]
[-- Type: text/x-diff, Size: 6119 bytes --]

From 0fd8f65bb87b11ef8ae366a797aec572d67b284f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@codesourcery.com>
Date: Fri, 30 Jun 2023 13:23:55 +0200
Subject: [PATCH] [WIP] Adjust LTO mode tables for "Machine_Mode: Extend
 machine_mode from 8 to 16 bits"

---
 gcc/lto-streamer-in.cc |  2 +-
 gcc/lto-streamer.h     | 56 +++++++++++++++++++++++++++++++++++++++++-
 gcc/lto/lto-common.cc  | 10 ++++----
 gcc/lto/lto-common.h   |  2 +-
 gcc/tree-streamer.h    |  2 +-
 5 files changed, 63 insertions(+), 9 deletions(-)

diff --git a/gcc/lto-streamer-in.cc b/gcc/lto-streamer-in.cc
index 1876e1967ec..bbd44504ff8 100644
--- a/gcc/lto-streamer-in.cc
+++ b/gcc/lto-streamer-in.cc
@@ -1997,7 +1997,7 @@ lto_input_mode_table (struct lto_file_decl_data *file_data)
   bitpack_d bp = streamer_read_bitpack (&ib);
 
   unsigned mode_bits = bp_unpack_value (&bp, 5);
-  unsigned char *table = ggc_cleared_vec_alloc<unsigned char> (1 << mode_bits);
+  machine_mode *table = ggc_cleared_vec_alloc<machine_mode> (1 << mode_bits);
 
   file_data->mode_table = table;
   file_data->mode_bits = mode_bits;
diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h
index 0556b34c837..4d83741e4c6 100644
--- a/gcc/lto-streamer.h
+++ b/gcc/lto-streamer.h
@@ -596,7 +596,61 @@ struct GTY(()) lto_file_decl_data
   hash_map<tree, ld_plugin_symbol_resolution> * GTY((skip)) resolution_map;
 
   /* Mode translation table.  */
-  const unsigned char *mode_table;
+  /*TODO const
+With 'const', we get:
+
+    gtype-desc.cc: In function 'void gt_pch_nx_lto_file_decl_data(void*)':
+    gtype-desc.cc:6531:34: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
+             gt_pch_note_object ((*x).mode_table, x, gt_pch_p_18lto_file_decl_data);
+                                      ^
+    In file included from [...]/source-gcc/gcc/hash-table.h:247:0,
+                     from [...]/source-gcc/gcc/coretypes.h:486,
+                     from gtype-desc.cc:23:
+    [...]/source-gcc/gcc/ggc.h:47:12: note:   initializing argument 1 of 'int gt_pch_note_object(void*, void*, gt_note_pointers, size_t)'
+     extern int gt_pch_note_object (void *, void *, gt_note_pointers,
+                ^
+    make[2]: *** [Makefile:1180: gtype-desc.o] Error 1
+   */
+  machine_mode * GTY((atomic)) mode_table;
+  /*
+This (without 'const') changes '[build-gcc]/gcc/gtype-desc.cc' as follows:
+
+    @@ -2566,7 +2566,9 @@ gt_ggc_mx_lto_file_decl_data (void *x_p)
+           gt_ggc_m_17lto_in_decl_state ((*x).global_decl_state);
+           gt_ggc_m_29hash_table_decl_state_hasher_ ((*x).function_decl_states);
+           gt_ggc_m_18lto_file_decl_data ((*x).next);
+    -      gt_ggc_m_S ((*x).mode_table);
+    +      if ((*x).mode_table != NULL) {
+    +        ggc_mark ((*x).mode_table);
+    +      }
+         }
+     }
+     
+    @@ -6525,7 +6527,9 @@ gt_pch_nx_lto_file_decl_data (void *x_p)
+           gt_pch_n_17lto_in_decl_state ((*x).global_decl_state);
+           gt_pch_n_29hash_table_decl_state_hasher_ ((*x).function_decl_states);
+           gt_pch_n_18lto_file_decl_data ((*x).next);
+    -      gt_pch_n_S ((*x).mode_table);
+    +      if ((*x).mode_table != NULL) {
+    +        gt_pch_note_object ((*x).mode_table, x, gt_pch_p_18lto_file_decl_data);
+    +      }
+         }
+     }
+     
+    @@ -10929,8 +10933,10 @@ gt_pch_p_18lto_file_decl_data (ATTRIBUTE
+         op (&((*x).function_decl_states), NULL, cookie);
+       if ((void *)(x) == this_obj)
+         op (&((*x).next), NULL, cookie);
+    -  if ((void *)(x) == this_obj)
+    -    op (&((*x).mode_table), NULL, cookie);
+    +  if ((*x).mode_table != NULL) {
+    +    if ((void *)(x) == this_obj)
+    +      op (&((*x).mode_table), NULL, cookie);
+    +  }
+     }
+
+Given that the '[...]_S' routines are for strings (due to previous 'char *', I suppose), that's probably correct?
+   */
 
   /* Read LTO section.  */
   lto_section lto_section_header;
diff --git a/gcc/lto/lto-common.cc b/gcc/lto/lto-common.cc
index 973ab791712..f483f42997e 100644
--- a/gcc/lto/lto-common.cc
+++ b/gcc/lto/lto-common.cc
@@ -64,7 +64,7 @@ static bool type_streaming_finished = false;
 
 GTY(()) tree first_personality_decl;
 
-GTY(()) const unsigned char *lto_mode_identity_table;
+GTY(()) const machine_mode *lto_mode_identity_table;
 
 /* Returns a hash code for P.  */
 
@@ -2274,7 +2274,7 @@ lto_file_finalize (struct lto_file_decl_data *file_data, lto_file *file,
 #ifdef ACCEL_COMPILER
   lto_input_mode_table (file_data);
 #else
-  file_data->mode_table = lto_mode_identity_table;
+  file_data->mode_table = /*TODO const*/ (machine_mode *) lto_mode_identity_table;
   file_data->mode_bits = ceil_log2 (MAX_MACHINE_MODE);
 #endif
 
@@ -3116,10 +3116,10 @@ lto_fe_init (void)
   bitmap_obstack_initialize (NULL);
   gimple_register_cfg_hooks ();
 #ifndef ACCEL_COMPILER
-  unsigned char *table
-    = ggc_vec_alloc<unsigned char> (MAX_MACHINE_MODE);
+  machine_mode *table
+    = ggc_vec_alloc<machine_mode> (MAX_MACHINE_MODE);
   for (int m = 0; m < MAX_MACHINE_MODE; m++)
-    table[m] = m;
+    table[m] = (machine_mode) m;
   lto_mode_identity_table = table;
 #endif
 }
diff --git a/gcc/lto/lto-common.h b/gcc/lto/lto-common.h
index 24b2445673b..2b868085139 100644
--- a/gcc/lto/lto-common.h
+++ b/gcc/lto/lto-common.h
@@ -26,7 +26,7 @@ void print_lto_report_1 (void);
 
 extern tree lto_eh_personality_decl;
 extern GTY(()) vec<tree, va_gc> *tree_with_vars;
-extern const unsigned char *lto_mode_identity_table;
+extern const machine_mode *lto_mode_identity_table;
 extern tree first_personality_decl;
 
 #endif
diff --git a/gcc/tree-streamer.h b/gcc/tree-streamer.h
index ff49d1ba637..1e346b775e6 100644
--- a/gcc/tree-streamer.h
+++ b/gcc/tree-streamer.h
@@ -118,7 +118,7 @@ bp_unpack_machine_mode (struct bitpack_d *bp)
   lto_input_block *ib = (class lto_input_block *) bp->stream;
   int last = 1 << ib->file_data->mode_bits;
   unsigned ix = bp_unpack_enum (bp, machine_mode, last);
-  return (machine_mode) ib->file_data->mode_table[ix];
+  return ib->file_data->mode_table[ix];
 }
 
 #endif  /* GCC_TREE_STREAMER_H  */
-- 
2.34.1


  parent reply	other threads:[~2023-06-30 11:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-12  5:00 [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits pan2.li
2023-05-12  6:49 ` Richard Biener
2023-05-12 19:14   ` Bernhard Reutner-Fischer
2023-05-13  8:44     ` Kito Cheng
2023-05-13 12:26       ` Li, Pan2
2023-06-30 11:46       ` Thomas Schwinge [this message]
2023-06-30 12:45         ` Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 bits" (was: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits) Kito Cheng
2023-06-30 16:11           ` Thomas Schwinge
2023-06-30 16:37           ` Jakub Jelinek
2023-07-04 15:45             ` Thomas Schwinge
     [not found]         ` <MW5PR11MB590876BB7E52B78E837C95C9A913A@MW5PR11MB5908.namprd11.prod.outlook.com>
     [not found]           ` <CAFiYyc0Ajoi__g1YJhdrh-Z3DsOyU7+1iG6SEmZMDzAShX-L6g@mail.gmail.com>
     [not found]             ` <MW5PR11MB5908E5743F472D48ACF60039A913A@MW5PR11MB5908.namprd11.prod.outlook.com>
2023-08-10 13:23               ` Machine Mode ICE in RISC-V when LTO Thomas Schwinge
2023-08-10 14:14                 ` Li, Pan2
2023-08-11  6:40                   ` Li, Pan2
2023-09-15 13:33                     ` Robin Dapp
2023-09-18 14:46                       ` LTO: Get rid of 'lto_mode_identity_table' (was: Machine Mode ICE in RISC-V when LTO) Thomas Schwinge
2023-09-18 14:53                         ` Richard Biener
2023-05-12  8:24 ` [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits Richard Sandiford
2023-05-12 11:16   ` Li, Pan2
2023-05-12 11:31     ` Richard Sandiford
2023-05-12 11:48       ` Li, Pan2
2023-05-16 15:35 ` pan2.li
2023-05-18  8:57   ` Richard Sandiford
2023-05-18  9:17     ` Li, Pan2
     [not found] <Message-Id: <20230512050016.476110-1-pan2.li@intel.com>
2023-05-12 15:38 ` [PATCH v2] " pan2.li
2023-05-13 13:13 ` [PATCH v3] " pan2.li
2023-05-16  1:12   ` Li, Pan2
2023-05-16  7:29     ` Richard Sandiford
2023-05-16  7:55       ` Li, Pan2
2023-05-16  8:03         ` Xi Ruoyao
2023-05-16  8:05           ` Li, Pan2
2023-05-16  9:09   ` Richard Sandiford
2023-05-16 12:17     ` Li, Pan2
2023-05-16 15:39       ` Li, Pan2

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=87o7kxuq9s.fsf@euler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=juzhe.zhong@rivai.ai \
    --cc=kito.cheng@sifive.com \
    --cc=pan2.li@intel.com \
    --cc=rep.dot.nop@gmail.com \
    --cc=rguenther@suse.de \
    --cc=richard.sandiford@arm.com \
    --cc=yanzhang.wang@intel.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).