On Mon, Apr 10, 2023 at 10:48:08PM +0800, juzhe.zh...@rivai.ai wrote:
> * rtl.h (struct GTY): Ditto.
> --- a/gcc/rtl.h
> +++ b/gcc/rtl.h
> @@ -313,7 +313,7 @@ struct GTY((desc("0"), tag("0"),
> ENUM_BITFIELD(rtx_code) code: 16;
>
> /* 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.
At least for struct rtx_def this is certainly unacceptable.
The widely used structure is carefully laid out so that it doesn't waste any
bits - there are 16 + 8 + 8 bits, then 32-bit union, and then union of
something that needs on 64-bit hosts 64-bit alignment. So header nicely 64
bits before the variable sized payloads.
The above change grows that to 16 + 16 + 8 bits, the 32-bit union needs
32-bit alignment, so that is already 96 bits, and then the payload which
needs 64-bit alignment, so the above change grows the rtl header by 100%,
from 64-bits to 128-bits.
> --- a/gcc/tree-core.h
> +++ b/gcc/tree-core.h
> @@ -1693,7 +1693,7 @@ struct GTY(()) tree_type_common {
> unsigned restrict_flag : 1;
> unsigned contains_placeholder_bits : 2;
>
> - ENUM_BITFIELD(machine_mode) mode : 8;
> + 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. */
This structure has 15 spare bits, so in theory it could be accomodated to
handle more bits for mode, but the above change is insufficient for that.
> @@ -1776,7 +1776,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;
I think this one has 13 spare bits, but again one would need to adjust the
structure more so that it doesn't grow unnecessarily.
I think you should try hard to avoid having too many modes, there are a lot
of arrays especially in RA sized by number of modes or even that times
number of register classes (I thought we have some number of modes ^ 2
but can't find them right now), and if there is no way to avoid that,
we should consider making those changes dependent on maximum number of modes
and use current more compact compile time memory data structures unless
the target has more than 256 modes.
Jakub
