RE: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

["Li, Pan2" <pan2.li@intel.com>]

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

Picked all changes mentioned in previous to single patch as attachment. Please help to review if any mistake.

Pan

-----Original Message-----
From: Li, Pan2 
Sent: Saturday, May 6, 2023 10:20 AM
To: Kito Cheng <kito.cheng@gmail.com>
Cc: juzhe.zhong@rivai.ai; rguenther <rguenther@suse.de>; richard.sandiford <richard.sandiford@arm.com>; jeffreyalaw <jeffreyalaw@gmail.com>; gcc-patches <gcc-patches@gcc.gnu.org>; palmer <palmer@dabbelt.com>; jakub <jakub@redhat.com>
Subject: RE: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

Yes, that makes sense, will have a try and keep you posted.

Pan

-----Original Message-----
From: Kito Cheng <kito.cheng@gmail.com>
Sent: Saturday, May 6, 2023 10:19 AM
To: Li, Pan2 <pan2.li@intel.com>
Cc: juzhe.zhong@rivai.ai; rguenther <rguenther@suse.de>; richard.sandiford <richard.sandiford@arm.com>; jeffreyalaw <jeffreyalaw@gmail.com>; gcc-patches <gcc-patches@gcc.gnu.org>; palmer <palmer@dabbelt.com>; jakub <jakub@redhat.com>
Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit

I think x86 first? The major thing we want to make sure is that this change won't affect those targets which do not really require 16 bit machine_mode too much.


On Sat, May 6, 2023 at 10:12 AM Li, Pan2 via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>
> Sure thing, I will pick them all together and trigger(will send out the overall diff before start to make sure my understand is correct) the test again. BTW which target do we prefer first? X86 or RISC-V.
>
> Pan
>
> From: juzhe.zhong@rivai.ai <juzhe.zhong@rivai.ai>
> Sent: Saturday, May 6, 2023 10:00 AM
> To: kito.cheng <kito.cheng@gmail.com>; Li, Pan2 <pan2.li@intel.com>
> Cc: rguenther <rguenther@suse.de>; richard.sandiford 
> <richard.sandiford@arm.com>; jeffreyalaw <jeffreyalaw@gmail.com>; 
> gcc-patches <gcc-patches@gcc.gnu.org>; palmer <palmer@dabbelt.com>; 
> jakub <jakub@redhat.com>
> Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 
> 8-bit to 16-bit
>
> Yeah, you should also swap mode and code in rtx_def according to 
> Richard suggestion since it will not change the rtx_def data structure.
>
> I think the only problem is the mode in tree data structure.
> ________________________________
> juzhe.zhong@rivai.ai<mailto:juzhe.zhong@rivai.ai>
>
> From: Kito Cheng<mailto:kito.cheng@gmail.com>
> Date: 2023-05-06 09:53
> To: Li, Pan2<mailto:pan2.li@intel.com>
> CC: Richard Biener<mailto:rguenther@suse.de>;
> 钟居哲<mailto:juzhe.zhong@rivai.ai>;
> richard.sandiford<mailto:richard.sandiford@arm.com>; Jeff 
> Law<mailto:jeffreyalaw@gmail.com>;
> gcc-patches<mailto:gcc-patches@gcc.gnu.org>;
> palmer<mailto:palmer@dabbelt.com>; jakub<mailto:jakub@redhat.com>
> Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size from 
> 8-bit to 16-bit Hi Pan:
>
> Could you try to apply the following diff and measure again? This 
> makes tree_type_common size unchanged.
>
>
> sizeof tree_type_common= 128 (mode = 8 bit) sizeof tree_type_common=
> 136 (mode = 16 bit) sizeof tree_type_common= 128 (mode = 8 bit w/ this
> diff)
>
> diff --git a/gcc/tree-core.h b/gcc/tree-core.h index
> af795aa81f98..b8ccfa407ed9 100644
> --- a/gcc/tree-core.h
> +++ b/gcc/tree-core.h
> @@ -1680,6 +1680,8 @@ struct GTY(()) tree_type_common {
>   tree attributes;
>   unsigned int uid;
>
> +  ENUM_BITFIELD(machine_mode) mode : 16;
> +
>   unsigned int precision : 10;
>   unsigned no_force_blk_flag : 1;
>   unsigned needs_constructing_flag : 1; @@ -1687,7 +1689,6 @@ struct
> GTY(()) tree_type_common {
>   unsigned restrict_flag : 1;
>   unsigned contains_placeholder_bits : 2;
>
> -  ENUM_BITFIELD(machine_mode) mode : 16;
>
>   /* TYPE_STRING_FLAG for INTEGER_TYPE and ARRAY_TYPE.
>      TYPE_CXX_ODR_P for RECORD_TYPE and UNION_TYPE.  */ @@ -1712,7
> +1713,7 @@ struct GTY(()) tree_type_common {
>   unsigned empty_flag : 1;
>   unsigned indivisible_p : 1;
>   unsigned no_named_args_stdarg_p : 1;
> -  unsigned spare : 15;
> +  unsigned spare : 7;
>
>   alias_set_type alias_set;
>   tree pointer_to;
>
> On Sat, May 6, 2023 at 9:10 AM Li, Pan2 via Gcc-patches 
> <gcc-patches@gcc.gnu.org<mailto:gcc-patches@gcc.gnu.org>> wrote:
> >
> > Yes, totally agree the number cannot be very accurate up to a point. Update the correlated memory bytes allocated for the X86 target.
> >
> > Bytes allocated with O2:
> > -----------------------------------------------------------------------------------------------------
> > Benchmark               |  upstream             | with this PATCH
> > -----------------------------------------------------------------------------------------------------
> > 400.perlbench           | 25286185160           | 25176544846 ~0.0%
> > 401.bzip2               | 1429883731            | 1391040027 -2.7%
> > 403.gcc                 | 55023568981           | 54798890746 ~0.0%
> > 429.mcf         | 1360975660            | 1321537710 -2.9%
> > 445.gobmk               | 12791636502           | 12666523431 -1.0%
> > 456.hmmer               | 9354433652            | 9279189174 ~0.0%
> > 458.sjeng               | 1991260562            | 1944031904 -2.4%
> > 462.libquantum          | 1725112078            | 1684213981 -2.4%
> > 464.h264ref             | 8597673515            | 8528855778 ~0.0%
> > 471.omnetpp             | 37613034778           | 37432278047 ~0.0%
> > 473.astar               | 3817295518            | 3772460508 -1.2%
> > 483.xalancbmk           | 149418776991  | 148545162207 ~0.0%
> >
> > Bytes allocated with Ofast + funroll-loops:
> > ------------------------------------------------------------------------------------------
> > Benchmark               |  upstream             | with this PATCH
> > ------------------------------------------------------------------------------------------
> > 400.perlbench           | 30438407499           | 30574152897 ~0.0%
> > 401.bzip2               | 2277114519            | 2319432664 +1.9%
> > 403.gcc                 | 64499664264           | 64781232731 ~0.0%
> > 429.mcf         | 1361486758            | 1399942116 +2.8%
> > 445.gobmk               | 15258056111           | 15396801542 +1.0%
> > 456.hmmer               | 10896615649           | 10936223486 ~0.0%
> > 458.sjeng               | 2592620709            | 2641687496 +1.9%
> > 462.libquantum          | 1814487525            | 1854518500 +2.2%
> > 464.h264ref             | 13528736878           | 13614517066 ~0.0%
> > 471.omnetpp             | 38721066702           | 38910524667 ~0.0%
> > 473.astar               | 3924015756            | 3968057027 +1.1%
> > 483.xalancbmk           | 165897692838  | 166843885880 ~0.0%
> >
> > Pan
> >
> >
> > -----Original Message-----
> > From: Richard Biener <rguenther@suse.de<mailto:rguenther@suse.de>>
> > Sent: Friday, May 5, 2023 2:25 PM
> > To: Li, Pan2 <pan2.li@intel.com<mailto:pan2.li@intel.com>>
> > Cc: 钟居哲 <juzhe.zhong@rivai.ai<mailto:juzhe.zhong@rivai.ai>>;
> > kito.cheng <kito.cheng@gmail.com<mailto:kito.cheng@gmail.com>>;
> > richard.sandiford
> > <richard.sandiford@arm.com<mailto:richard.sandiford@arm.com>>; Jeff 
> > Law <jeffreyalaw@gmail.com<mailto:jeffreyalaw@gmail.com>>;
> > gcc-patches
> > <gcc-patches@gcc.gnu.org<mailto:gcc-patches@gcc.gnu.org>>; palmer 
> > <palmer@dabbelt.com<mailto:palmer@dabbelt.com>>; jakub 
> > <jakub@redhat.com<mailto:jakub@redhat.com>>
> > Subject: RE: Re: [PATCH] machine_mode type size: Extend enum size 
> > from 8-bit to 16-bit
> >
> > On Fri, 5 May 2023, Li, Pan2 wrote:
> >
> > > I tried the memory profiling by valgrind --tool=memcheck --trace-children=yes for this change, target the SPEC 2006 INT part with rv64gcv. Note we only count the bytes allocated from valgrind log like this "==2832896==   total heap usage: 208 allocs, 165 frees, 123,204 bytes allocated".
> > >
> > > Consider some variance of valgrind, it looks like the impact to 
> > > bytes allocated may be limited. However, I am still running this 
> > > for x86, it will take more than 30 hours for each iteration...
> >
> > I'm not sure I'd call +- 7% on memory use "limited" - but I fear the numbers are off.  Note since various structures reside in GC memory there's also changes to GC overhead and fragmentation, so precise measurements are difficult.
> >
> > Richard.
> >
> > > RISC-V GCC Version:
> > > >> ~/bin/test-gnu-8-bits/bin/riscv64-unknown-linux-gnu-gcc
> > > >> --version
> > > riscv64-unknown-linux-gnu-gcc (gd7cb9720ed5) 14.0.0 20230503
> > > (experimental) Copyright (C) 2023 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions.  
> > > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > >
> > > Bytes allocated with O2:
> > > -----------------------------------------------------------------------------------------------------
> > > Benchmark             |  upstream             | with this PATCH
> > > -----------------------------------------------------------------------------------------------------
> > > 400.perlbench         | 29699642875           | 29949876269 ~0.0%
> > > 401.bzip2             | 1641041659            | 1755563972 +6.95%
> > > 403.gcc                       | 68447500516           | 68900883291 ~0.0%
> > > 429.mcf               | 1433156462            | 1433253373 ~0.0%
> > > 445.gobmk             | 14239225210           | 14463438465 ~0.0%
> > > 456.hmmer             | 9635955623            | 9808534948 +1.8%
> > > 458.sjeng             | 2419478204            | 2545478940 +5.4%
> > > 462.libquantum                | 1686404489            | 1800884197 +6.8%
> > > 464.h264ref   8j1     | 10190413900           | 10351134161 +1.6%
> > > 471.omnetpp           | 40814627684           | 41185864529 ~0.0%
> > > 473.astar             | 3807097529            | 3928428183 +3.2%
> > > 483.xalancbmk         | 152959418167  | 154201738843 ~0.0%
> > >
> > > Bytes allocated with Ofast + funroll-loops:
> > > ------------------------------------------------------------------------------------------
> > > Benchmark             |  upstream             | with this PATCH
> > > ------------------------------------------------------------------------------------------
> > > 400.perlbench         |  39491184733          | 39223020267 ~0.0%
> > > 401.bzip2             |  2843871517           | 2730383463 ~0%
> > > 403.gcc                       |  84195991898          | 83730632955 -4.0%
> > > 429.mcf               |  1481381164           | 1367309565 -7.7%
> > > 445.gobmk             |  20123943663          | 19886116394 -1.2%
> > > 456.hmmer             |  12302445139          | 12121745383 -1.5%
> > > 458.sjeng             |  3884712615           | 3755481930  -3.3%
> > > 462.libquantum                |  1966619940           | 1852274342  -5.8%
> > > 464.h264ref           |  19219365552          | 19050288201 ~0.0%
> > > 471.omnetpp           |  45701008325          | 45327805079 ~0.0%
> > > 473.astar             |  4118600354           | 3995943705 -3.0%
> > > 483.xalancbmk         |  179481305182 | 178160306301 ~0.0%
> > >
> > > Pan
> > >
> > >
> > > -----Original Message-----
> > > From: Gcc-patches <gcc-patches-bounces+pan2.li=intel.com@gcc.gnu.org<mailto:gcc-patches-bounces+pan2.li=intel.com@gcc.gnu.org>> On Behalf Of ???
> > > Sent: Thursday, April 13, 2023 7:23 AM
> > > To: kito.cheng
> > > <kito.cheng@gmail.com<mailto:kito.cheng@gmail.com>>; rguenther 
> > > <rguenther@suse.de<mailto:rguenther@suse.de>>
> > > Cc: richard.sandiford
> > > <richard.sandiford@arm.com<mailto:richard.sandiford@arm.com>>;
> > > Jeff Law <jeffreyalaw@gmail.com<mailto:jeffreyalaw@gmail.com>>;
> > > gcc-patches
> > > <gcc-patches@gcc.gnu.org<mailto:gcc-patches@gcc.gnu.org>>; palmer 
> > > <palmer@dabbelt.com<mailto:palmer@dabbelt.com>>; jakub 
> > > <jakub@redhat.com<mailto:jakub@redhat.com>>
> > > Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size 
> > > from 8-bit to 16-bit
> > >
> > > Yeah, like kito said.
> > > Turns out the tuple type model in ARM SVE is the optimal solution for RVV.
> > > And we like ARM SVE style implmentation.
> > >
> > > And now we see swapping rtx_code and mode in rtx_def can make rtx_def overal not exceed 64 bit.
> > > But it seems that there is still problem in tree_type_common and tree_decl_common, is that right?
> > >
> > > After several trys (remove all redundant TI/TF vector modes and FP16 vector mode), now there are 252 modes in RISC-V port. Basically, I can keep supporting new RVV intrinsisc features recently.
> > > However, we can't support more in the future, for example, FP16 vector, BF16 vector, matrix modes, VLS modes,...etc.
> > >
> > > From RVV side, I think extending 1 more bit of machine mode should be enough for RVV (overal 512 modes).
> > > Is it possible make it happen in tree_type_common and tree_decl_common, Richards?
> > >
> > > Thank you so much for all comments.
> > >
> > >
> > > juzhe.zhong@rivai.ai<mailto:juzhe.zhong@rivai.ai>
> > >
> > > From: Kito Cheng
> > > Date: 2023-04-12 17:31
> > > To: Richard Biener
> > > CC: juzhe.zhong@rivai.ai<mailto:juzhe.zhong@rivai.ai>;
> > > richard.sandiford; jeffreyalaw; gcc-patches; palmer; jakub
> > > Subject: Re: Re: [PATCH] machine_mode type size: Extend enum size 
> > > from 8-bit to 16-bit
> > > > > The concept of fractional LMUL is the same as the concept of 
> > > > > AArch64's partial SVE vectors, so they can only access the 
> > > > > lowest part, like SVE's partial vector.
> > > > >
> > > > > We want to spill/restore the exact size of those modes (1/2, 
> > > > > 1/4, 1/8), so adding dedicated modes for those partial vector 
> > > > > modes should be unavoidable IMO.
> > > > >
> > > > > And even if we use sub-vector, we still need to define those 
> > > > > partial vector types.
> > > >
> > > > Could you use integer modes for the fractional vectors?
> > >
> > > You mean using the scalar integer mode like using (subreg:SI
> > > (reg:VNx4SI) 0) to represent
> > > LMUL=1/4?
> > > (Assume VNx4SI is mode for M1)
> > >
> > > If so I think it might not be able to model that right - it seems like we are using 32-bits but actually we are using poly_int16(1, 1) * 32 bits.
> > >
> > > > For computation you can always appropriately limit the LEN?
> > >
> > > RVV provide zvl*b extension like zvl<N>b (e.g.zvl128b or zvl256b) 
> > > to guarantee the vector length is at least larger than N bits, but 
> > > it's just guarantee the minimal length like SVE guarantee the 
> > > minimal vector length is 128 bits
> > >
> > >
> >
> > --
> > Richard Biener <rguenther@suse.de<mailto: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)
>

[-- Attachment #2: tmp.patch --]
[-- Type: application/octet-stream, Size: 6684 bytes --]

diff --git a/gcc/combine.cc b/gcc/combine.cc
index 5aa0ec5c45a..3939c6cac66 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -200,7 +200,7 @@ struct reg_stat_type {
 
   unsigned HOST_WIDE_INT	last_set_nonzero_bits;
   char				last_set_sign_bit_copies;
-  ENUM_BITFIELD(machine_mode)	last_set_mode : 8;
+  ENUM_BITFIELD(machine_mode)	last_set_mode : 16;
 
   /* Set nonzero if references to register n in expressions should not be
      used.  last_set_invalid is set nonzero when this register is being
@@ -235,7 +235,7 @@ struct reg_stat_type {
      truncation if we know that value already contains a truncated
      value.  */
 
-  ENUM_BITFIELD(machine_mode)	truncated_to_mode : 8;
+  ENUM_BITFIELD(machine_mode)	truncated_to_mode : 16;
 };
 
 
diff --git a/gcc/cse.cc b/gcc/cse.cc
index b10c9b0c94d..ea970c737dd 100644
--- a/gcc/cse.cc
+++ b/gcc/cse.cc
@@ -250,8 +250,8 @@ struct qty_table_elem
   unsigned int first_reg, last_reg;
   /* The sizes of these fields should match the sizes of the
      code and mode fields of struct rtx_def (see rtl.h).  */
-  ENUM_BITFIELD(rtx_code) comparison_code : 16;
-  ENUM_BITFIELD(machine_mode) mode : 8;
+  ENUM_BITFIELD(rtx_code) comparison_code : 8;
+  ENUM_BITFIELD(machine_mode) mode : 16;
 };
 
 /* The table of all qtys, indexed by qty number.  */
@@ -406,7 +406,7 @@ struct table_elt
   int regcost;
   /* The size of this field should match the size
      of the mode field of struct rtx_def (see rtl.h).  */
-  ENUM_BITFIELD(machine_mode) mode : 8;
+  ENUM_BITFIELD(machine_mode) mode : 16;
   char in_memory;
   char is_const;
   char flag;
@@ -4155,7 +4155,7 @@ struct set
   /* Original machine mode, in case it becomes a CONST_INT.
      The size of this field should match the size of the mode
      field of struct rtx_def (see rtl.h).  */
-  ENUM_BITFIELD(machine_mode) mode : 8;
+  ENUM_BITFIELD(machine_mode) mode : 16;
   /* Hash value of constant equivalent for SET_SRC.  */
   unsigned src_const_hash;
   /* A constant equivalent for SET_SRC, if any.  */
diff --git a/gcc/genopinit.cc b/gcc/genopinit.cc
index 83cb7504fa1..3ca3e9fd946 100644
--- a/gcc/genopinit.cc
+++ b/gcc/genopinit.cc
@@ -182,7 +182,7 @@ main (int argc, const char **argv)
 
   progname = "genopinit";
 
-  if (NUM_OPTABS > 0xffff || MAX_MACHINE_MODE >= 0xff)
+  if (NUM_OPTABS > 0xffff || MAX_MACHINE_MODE >= 0xffff)
     fatal ("genopinit range assumptions invalid");
 
   if (!init_rtx_reader_args_cb (argc, argv, handle_arg))
diff --git a/gcc/ira-int.h b/gcc/ira-int.h
index e2de47213b4..65ec1678146 100644
--- a/gcc/ira-int.h
+++ b/gcc/ira-int.h
@@ -281,10 +281,10 @@ struct ira_allocno
   int regno;
   /* Mode of the allocno which is the mode of the corresponding
      pseudo-register.  */
-  ENUM_BITFIELD (machine_mode) mode : 8;
+  ENUM_BITFIELD (machine_mode) mode : 16;
   /* Widest mode of the allocno which in at least one case could be
      for paradoxical subregs where wmode > mode.  */
-  ENUM_BITFIELD (machine_mode) wmode : 8;
+  ENUM_BITFIELD (machine_mode) wmode : 16;
   /* Register class which should be used for allocation for given
      allocno.  NO_REGS means that we should use memory.  */
   ENUM_BITFIELD (reg_class) aclass : 16;
diff --git a/gcc/ree.cc b/gcc/ree.cc
index 413aec7c8eb..e74b96cdfac 100644
--- a/gcc/ree.cc
+++ b/gcc/ree.cc
@@ -567,7 +567,7 @@ enum ext_modified_kind
 struct ATTRIBUTE_PACKED ext_modified
 {
   /* Mode from which ree has zero or sign extended the destination.  */
-  ENUM_BITFIELD(machine_mode) mode : 8;
+  ENUM_BITFIELD(machine_mode) mode : 16;
 
   /* Kind of modification of the insn.  */
   ENUM_BITFIELD(ext_modified_kind) kind : 2;
diff --git a/gcc/rtl-ssa/accesses.h b/gcc/rtl-ssa/accesses.h
index c5180b9308a..3c928058490 100644
--- a/gcc/rtl-ssa/accesses.h
+++ b/gcc/rtl-ssa/accesses.h
@@ -254,7 +254,7 @@ private:
   unsigned int m_spare : 2;
 
   // The value returned by the accessor above.
-  machine_mode m_mode : 8;
+  machine_mode m_mode : 16;
 };
 
 // A contiguous array of access_info pointers.  Used to represent a
diff --git a/gcc/rtl.h b/gcc/rtl.h
index f634cab730b..4b1deb34840 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -310,10 +310,10 @@ struct GTY((desc("0"), tag("0"),
 	    chain_next ("RTX_NEXT (&%h)"),
 	    chain_prev ("RTX_PREV (&%h)"))) rtx_def {
   /* The kind of expression this is.  */
-  ENUM_BITFIELD(rtx_code) code: 16;
+  ENUM_BITFIELD(rtx_code) code: 8;
 
   /* The kind of value the expression has.  */
-  ENUM_BITFIELD(machine_mode) mode : 8;
+  ENUM_BITFIELD(machine_mode) mode : 16;
 
   /* 1 in a MEM if we should keep the alias set for this mem unchanged
      when we access a component.
@@ -2164,7 +2164,7 @@ subreg_shape::operator != (const subreg_shape &other) const
 inline unsigned HOST_WIDE_INT
 subreg_shape::unique_id () const
 {
-  { STATIC_ASSERT (MAX_MACHINE_MODE <= 256); }
+  { STATIC_ASSERT (MAX_MACHINE_MODE <= 32768); }
   { STATIC_ASSERT (NUM_POLY_INT_COEFFS <= 3); }
   { STATIC_ASSERT (sizeof (offset.coeffs[0]) <= 2); }
   int res = (int) inner_mode + ((int) outer_mode << 8);
diff --git a/gcc/rtlanal.h b/gcc/rtlanal.h
index 5fbed816e20..bdd84e39c76 100644
--- a/gcc/rtlanal.h
+++ b/gcc/rtlanal.h
@@ -100,7 +100,7 @@ public:
 
   /* The mode of the reference.  If IS_MULTIREG, this is the mode of
      REGNO - MULTIREG_OFFSET.  */
-  machine_mode mode : 8;
+  machine_mode mode : 16;
 
   /* If IS_MULTIREG, the offset of REGNO from the start of the register.  */
   unsigned int multireg_offset : 8;
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index 847f0b1e994..d7bb7d04d3f 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1680,6 +1680,8 @@ struct GTY(()) tree_type_common {
   tree attributes;
   unsigned int uid;
 
+  ENUM_BITFIELD(machine_mode) mode : 16;
+
   unsigned int precision : 10;
   unsigned no_force_blk_flag : 1;
   unsigned needs_constructing_flag : 1;
@@ -1687,8 +1689,6 @@ struct GTY(()) tree_type_common {
   unsigned restrict_flag : 1;
   unsigned contains_placeholder_bits : 2;
 
-  ENUM_BITFIELD(machine_mode) mode : 8;
-
   /* TYPE_STRING_FLAG for INTEGER_TYPE and ARRAY_TYPE.
      TYPE_CXX_ODR_P for RECORD_TYPE and UNION_TYPE.  */
   unsigned string_flag : 1;
@@ -1712,7 +1712,7 @@ struct GTY(()) tree_type_common {
   unsigned empty_flag : 1;
   unsigned indivisible_p : 1;
   unsigned no_named_args_stdarg_p : 1;
-  unsigned spare : 15;
+  unsigned spare : 7;
 
   alias_set_type alias_set;
   tree pointer_to;
@@ -1770,7 +1770,7 @@ struct GTY(()) tree_decl_common {
   struct tree_decl_minimal common;
   tree size;
 
-  ENUM_BITFIELD(machine_mode) mode : 8;
+  ENUM_BITFIELD(machine_mode) mode : 16;
 
   unsigned nonlocal_flag : 1;
   unsigned virtual_flag : 1;