Re: [trunk]: Patch to move BITS_PER_UNIT to be available for genmodes.c
On Wed, 11 Dec 2013, Kenneth Zadeck wrote: This patch is for the trunk, but it solves a problem that comes up for wide-int. For wide-int we need to have the BITS_PER_UNIT available earlier. So this patch sets the default value (8) in genmodes.c so that it is available by anyone who includes insn-modes.h. The generator for tm.h was modified to include insn-modes.h.The value for BITS_PER_UNIT can be overridden by any port by placing a define for it in their target modes file. This patch removes the definition of BITS_PER_UNIT from 7 platform .h files. All of those platforms initialized it to the default value so there was no need for additions to their target modes file. In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT is calculated.The value is heavily used on the wide-int branch to allocate buffers that are used to hold large integer values. The change in the way it is computed was motivated by the i386 port, but there may be other ports that have the same problem. The i386 port defines two very large integer modes that are only used as containers for large vectors. They are never used for large integers. The new way of computing this allows a port to say (very early) that some of these integer modes are never used to hold numbers and so smaller buffers can be used for integer calculations. Other ports that play the same game should follow suit. This patch has been bootstrapped and regression tested on x86-64. Ok to commit? Ok. Thanks, Richard. Kenny -- Richard Biener rguent...@suse.de SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imendorffer
Re: [trunk]: Patch to move BITS_PER_UNIT to be available for genmodes.c
Hello! In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT is calculated. The value is heavily used on the wide-int branch to allocate buffers that are used to hold large integer values. The change in the way it is computed was motivated by the i386 port, but there may be other ports that have the same problem. The i386 port defines two very large integer modes that are only used as containers for large vectors. They are never used for large integers. The new way of computing this allows a port to say (very early) that some of these integer modes are never used to hold numbers and so smaller buffers can be used for integer calculations. Other ports that play the same game should follow suit. Index: gcc/config/i386/i386-modes.def === --- gcc/config/i386/i386-modes.def (revision 205895) +++ gcc/config/i386/i386-modes.def (working copy) @@ -90,5 +90,10 @@ VECTOR_MODE (INT, QI, 2); /* INT_MODE (OI, 32); INT_MODE (XI, 64); +/* Keep the OI and XI modes from confusing the compiler into thinking + that these modes could actually be used for computation. They are + only holders for vectors during data movement. */ +#define MAX_BITSIZE_MODE_ANY_INT (128) + /* The symbol Pmode stands for one of the above machine modes (usually SImode). The tm.h file specifies which one. It is not a distinct mode. */ __int128 is avaialble only for x86_64 - 64bit targets, so: #define MAX_BITSIZE_MODE_ANY_INT (TARGET_64BIT ? 128 : 64) Uros.
Re: [trunk]: Patch to move BITS_PER_UNIT to be available for genmodes.c
On Fri, 13 Dec 2013, Uros Bizjak wrote: Hello! In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT is calculated. The value is heavily used on the wide-int branch to allocate buffers that are used to hold large integer values. The change in the way it is computed was motivated by the i386 port, but there may be other ports that have the same problem. The i386 port defines two very large integer modes that are only used as containers for large vectors. They are never used for large integers. The new way of computing this allows a port to say (very early) that some of these integer modes are never used to hold numbers and so smaller buffers can be used for integer calculations. Other ports that play the same game should follow suit. Index: gcc/config/i386/i386-modes.def === --- gcc/config/i386/i386-modes.def (revision 205895) +++ gcc/config/i386/i386-modes.def (working copy) @@ -90,5 +90,10 @@ VECTOR_MODE (INT, QI, 2); /* INT_MODE (OI, 32); INT_MODE (XI, 64); +/* Keep the OI and XI modes from confusing the compiler into thinking + that these modes could actually be used for computation. They are + only holders for vectors during data movement. */ +#define MAX_BITSIZE_MODE_ANY_INT (128) + /* The symbol Pmode stands for one of the above machine modes (usually SImode). The tm.h file specifies which one. It is not a distinct mode. */ __int128 is avaialble only for x86_64 - 64bit targets, so: #define MAX_BITSIZE_MODE_ANY_INT (TARGET_64BIT ? 128 : 64) It needs to be a compile-time constant. Richard.
Re: [trunk]: Patch to move BITS_PER_UNIT to be available for genmodes.c
On Dec 13, 2013, at 5:11 AM, Richard Biener rguent...@suse.de wrote: On Fri, 13 Dec 2013, Uros Bizjak wrote: Hello! In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT is calculated. The value is heavily used on the wide-int branch to allocate buffers that are used to hold large integer values. The change in the way it is computed was motivated by the i386 port, but there may be other ports that have the same problem. The i386 port defines two very large integer modes that are only used as containers for large vectors. They are never used for large integers. The new way of computing this allows a port to say (very early) that some of these integer modes are never used to hold numbers and so smaller buffers can be used for integer calculations. Other ports that play the same game should follow suit. Index: gcc/config/i386/i386-modes.def === --- gcc/config/i386/i386-modes.def (revision 205895) +++ gcc/config/i386/i386-modes.def (working copy) @@ -90,5 +90,10 @@ VECTOR_MODE (INT, QI, 2); /* INT_MODE (OI, 32); INT_MODE (XI, 64); +/* Keep the OI and XI modes from confusing the compiler into thinking + that these modes could actually be used for computation. They are + only holders for vectors during data movement. */ +#define MAX_BITSIZE_MODE_ANY_INT (128) + /* The symbol Pmode stands for one of the above machine modes (usually SImode). The tm.h file specifies which one. It is not a distinct mode. */ __int128 is avaialble only for x86_64 - 64bit targets, so: #define MAX_BITSIZE_MODE_ANY_INT (TARGET_64BIT ? 128 : 64) It needs to be a compile-time constant. Richard. I will add a line to the effect to the doc before checking it in.
Re: [trunk]: Patch to move BITS_PER_UNIT to be available for genmodes.c
committed as revision 205964 with updated comment.
kenny
2013-12-13 Kenneth Zadeck zad...@naturalbridge.com
* config/arc/arc.h (BITS_PER_UNIT): Removed.
* config/bfin/bfin.h (BITS_PER_UNIT): Removed.
* config/lm32/lm32.h (BITS_PER_UNIT): Removed.
* config/m32c/m32c.h (BITS_PER_UNIT): Removed.
* config/microblaze/microblaze.h (BITS_PER_UNIT): Removed.
* config/picochip/picochip.h (BITS_PER_UNIT): Removed.
* config/spu/spu.h (BITS_PER_UNIT): Removed.
* defaults.h (BITS_PER_UNIT): Removed.
* config/i386/i386-modes.def (MAX_BITSIZE_MODE_ANY_INT): New.
* doc/rtl (BITS_PER_UNIT): Moved from tm.texi.
(MAX_BITSIZE_MODE_ANY_INT): Updated.
* doc/tm.texi (BITS_PER_UNIT): Removed.
* doc/tm.texi.in (BITS_PER_UNIT): Removed.
* genmodes.c (bits_per_unit, max_bitsize_mode_any_int): New.
(create_modes): Added code to set bits_per_unit and
max_bitsize_mode_any_int.
(emit_max_int): Changed code generation.
* mkconfig.sh: Added insn-modes.h.
On 12/13/2013 06:11 AM, Richard Biener wrote:
On Fri, 13 Dec 2013, Uros Bizjak wrote:
Hello!
In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT is
calculated.
The value is heavily used on the wide-int branch to allocate buffers that are
used to hold large
integer values. The change in the way it is computed was motivated by the i386
port, but there
may be other ports that have the same problem. The i386 port defines two very
large integer
modes that are only used as containers for large vectors. They are never used
for large integers.
The new way of computing this allows a port to say (very early) that some of
these integer modes
are never used to hold numbers and so smaller buffers can be used for integer
calculations. Other
ports that play the same game should follow suit.
Index: gcc/config/i386/i386-modes.def
===
--- gcc/config/i386/i386-modes.def (revision 205895)
+++ gcc/config/i386/i386-modes.def (working copy)
@@ -90,5 +90,10 @@ VECTOR_MODE (INT, QI, 2); /*
INT_MODE (OI, 32);
INT_MODE (XI, 64);
+/* Keep the OI and XI modes from confusing the compiler into thinking
+ that these modes could actually be used for computation. They are
+ only holders for vectors during data movement. */
+#define MAX_BITSIZE_MODE_ANY_INT (128)
+
/* The symbol Pmode stands for one of the above machine modes (usually
SImode).
The tm.h file specifies which one. It is not a distinct mode. */
__int128 is avaialble only for x86_64 - 64bit targets, so:
#define MAX_BITSIZE_MODE_ANY_INT (TARGET_64BIT ? 128 : 64)
It needs to be a compile-time constant.
Richard.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 205962)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,24 @@
+2013-12-13 Kenneth Zadeck zad...@naturalbridge.com
+
+ * config/arc/arc.h (BITS_PER_UNIT): Removed.
+ * config/bfin/bfin.h (BITS_PER_UNIT): Removed.
+ * config/lm32/lm32.h (BITS_PER_UNIT): Removed.
+ * config/m32c/m32c.h (BITS_PER_UNIT): Removed.
+ * config/microblaze/microblaze.h (BITS_PER_UNIT): Removed.
+ * config/picochip/picochip.h (BITS_PER_UNIT): Removed.
+ * config/spu/spu.h (BITS_PER_UNIT): Removed.
+ * defaults.h (BITS_PER_UNIT): Removed.
+ * config/i386/i386-modes.def (MAX_BITSIZE_MODE_ANY_INT): New.
+ * doc/rtl (BITS_PER_UNIT): Moved from tm.texi.
+ (MAX_BITSIZE_MODE_ANY_INT): Updated.
+ * doc/tm.texi (BITS_PER_UNIT): Removed.
+ * doc/tm.texi.in (BITS_PER_UNIT): Removed.
+ * genmodes.c (bits_per_unit, max_bitsize_mode_any_int): New.
+ (create_modes): Added code to set bits_per_unit and
+ max_bitsize_mode_any_int.
+ (emit_max_int): Changed code generation.
+ * mkconfig.sh: Added insn-modes.h.
+
2013-12-13 Yuri Rumyantsev ysrum...@gmail.com
* config/i386/i386.c (slm_cost): Fix imul cost for HI.
Index: gcc/config/arc/arc.h
===
--- gcc/config/arc/arc.h (revision 205962)
+++ gcc/config/arc/arc.h (working copy)
@@ -303,9 +303,6 @@ along with GCC; see the file COPYING3.
numbered. */
#define WORDS_BIG_ENDIAN (TARGET_BIG_ENDIAN)
-/* Number of bits in an addressable storage unit. */
-#define BITS_PER_UNIT 8
-
/* Width in bits of a word, which is the contents of a machine register.
Note that this is not necessarily the width of data type `int';
if using 16-bit ints on a 68000, this would still be 32.
Index: gcc/config/bfin/bfin.h
===
--- gcc/config/bfin/bfin.h (revision 205962)
+++ gcc/config/bfin/bfin.h (working copy)
@@ -859,9 +859,6 @@ typedef struct {
/* Define this if most significant word of a multiword number is numbered. */
#define WORDS_BIG_ENDIAN 0
-/* number of bits in an addressable storage unit */
-#define BITS_PER_UNIT 8
-
/* Width in bits of a word, which is the contents of a machine register.
Note
Re: [trunk]: Patch to move BITS_PER_UNIT to be available for genmodes.c
On 12/11/13 17:35, Kenneth Zadeck wrote: This patch is for the trunk, but it solves a problem that comes up for wide-int. For wide-int we need to have the BITS_PER_UNIT available earlier.So this patch sets the default value (8) in genmodes.c so that it is available by anyone who includes insn-modes.h. The generator for tm.h was modified to include insn-modes.h.The value for BITS_PER_UNIT can be overridden by any port by placing a define for it in their target modes file. This patch removes the definition of BITS_PER_UNIT from 7 platform .h files. All of those platforms initialized it to the default value so there was no need for additions to their target modes file. In addition, this target also changes the way that MAX_BITSIZE_MODE_ANY_INT is calculated.The value is heavily used on the wide-int branch to allocate buffers that are used to hold large integer values. The change in the way it is computed was motivated by the i386 port, but there may be other ports that have the same problem. The i386 port defines two very large integer modes that are only used as containers for large vectors. They are never used for large integers. The new way of computing this allows a port to say (very early) that some of these integer modes are never used to hold numbers and so smaller buffers can be used for integer calculations. Other ports that play the same game should follow suit. This patch has been bootstrapped and regression tested on x86-64. Ok to commit? OK for MicroBlaze. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [trunk]: Patch to move BITS_PER_UNIT to be available for genmodes.c
The m32c part is OK.
Re: [trunk]: Patch to move BITS_PER_UNIT to be available for genmodes.c
On 12/11/2013 08:42 PM, DJ Delorie wrote: The m32c part is OK. thanks for the fast reply. kenny
