[PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Andrew Pinski]

When the HOST_WIDE_INT was changed over to 64bit the compile time for
most thing slowed.  GCSE was slower because it would call the functions
in libgcc as sbitmap used HOST_WIDE_INT unconditional even if it is
ineffiecent to use it.  This patch adds a check in config.host for
powerpc and i686 just so they both get the speedup when cross compiling
to targets which need 64bit HOST_WIDE_INT.  Anybody can add their host
to the list if this applies to them, I think sparc and/or mips but I
do not know enough about thier code generation to add them.

This speeds up compiling fold-const.i with -O3 by about 4 seconds
(from 81.8s to 77.9s).

OK? Bootstrapped on powerpc-apple-darwin and i686-pc-linux-gnu with no
regressions.

OK for 3.4 branch also?

Thanks,
Andrew Pinski


ChangeLog:
	* config.host (host_efficient64bit): New, set to yes defaultly.
	Set to no for powerpc-*-* and i686-*-*.
	* configure.ac: If !host_efficient64bit and need_64bit_hwint,
	define HOST_WIDE_INT_NOT_EFFICIENT.
	* configure: Regenerate.
	* config.in: Regenerate.
	* sbitmap.h: Use long instead of HOST_WIDE_INT if
	HOST_WIDE_INT_NOT_EFFICIENT is defined.


Patch:
Index: config.host
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config.host,v
retrieving revision 2.10
diff -u -p -r2.10 config.host
--- config.host	5 Jun 2004 07:28:25 -0000	2.10
+++ config.host	8 Jun 2004 03:51:27 -0000
@@ -52,6 +52,8 @@
 #
 #  host_can_use_collect2 Set to yes normally; to no if the host cannot
 #			link or otherwise use collect2
+#  host_efficient64bit Set to yes normally; to no if 64bit integers are
+#			 not as effiecient as 32bit integers
 
 # When setting any of these variables, check to see if a corresponding
 # variable is present in config.build; if so, you will likely want to 
@@ -66,6 +68,7 @@ host_extra_objs=
 host_extra_gcc_objs=
 out_host_hook_obj=host-default.o
 host_can_use_collect2=yes
+host_efficient64bit=yes
 
 # Unsupported hosts list.  Generally, only include hosts known to fail here,
 # since we allow hosts not listed to be supported generically.
@@ -80,6 +83,15 @@ case ${host} in
     ;;
 esac
 
+case ${host} in
+  powerpc-*-*)
+    host_efficient64bit=no
+    ;;
+  i?86-*-*)
+    host_efficient64bit=no
+    ;;
+esac
+
 # Machine-specific settings.
 case ${host} in
   alpha*-dec-*vms*)
Index: config.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config.in,v
retrieving revision 1.186
diff -u -p -r1.186 config.in
--- config.in	7 Jun 2004 08:17:35 -0000	1.186
+++ config.in	8 Jun 2004 03:51:27 -0000
@@ -475,6 +475,9 @@
 /* Define if your compiler supports the \`__int64' type. */
 #undef HAVE___INT64
 
+/* Define to 1 if HOST_WIDE_INT is not efficient for general use. */
+#undef HOST_WIDE_INT_NOT_EFFICIENT
+
 /* Define if the host machine stores words of multi-word integers in
    big-endian order. */
 #undef HOST_WORDS_BIG_ENDIAN
Index: configure
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure,v
retrieving revision 1.826
diff -u -p -r1.826 configure
--- configure	27 May 2004 19:47:36 -0000	1.826
+++ configure	8 Jun 2004 03:51:28 -0000
@@ -9258,6 +9258,14 @@ _ACEOF
 
 fi
 
+if test x$host_efficient64bit = xno -a x$need_64bit_hwint = xyes; then
+
+cat >>confdefs.h <<\_ACEOF
+#define HOST_WIDE_INT_NOT_EFFICIENT 1
+_ACEOF
+
+fi
+
 count=a
 for f in $host_xm_file; do
 	count=${count}x
Index: configure.ac
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.ac,v
retrieving revision 2.39
diff -u -p -r2.39 configure.ac
--- configure.ac	27 May 2004 19:47:36 -0000	2.39
+++ configure.ac	8 Jun 2004 03:51:28 -0000
@@ -1162,6 +1162,11 @@ if test x$need_64bit_hwint = xyes; then
 [Define to 1 if HOST_WIDE_INT must be 64 bits wide (see hwint.h).])
 fi
 
+if test x$host_efficient64bit = xno -a x$need_64bit_hwint = xyes; then
+	AC_DEFINE(HOST_WIDE_INT_NOT_EFFICIENT, 1,
+[Define to 1 if HOST_WIDE_INT is not efficient for general use.])
+fi
+
 count=a
 for f in $host_xm_file; do
 	count=${count}x
Index: sbitmap.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/sbitmap.h,v
retrieving revision 1.21
diff -u -p -r1.21 sbitmap.h
--- sbitmap.h	13 May 2004 06:39:45 -0000	1.21
+++ sbitmap.h	8 Jun 2004 03:51:29 -0000
@@ -25,8 +25,13 @@ Software Foundation, 59 Temple Place - S
    It should be straightforward to convert so for now we keep things simple
    while more important issues are dealt with.  */
 
+#ifdef HOST_WIDE_INT_NOT_EFFICIENT
+#define SBITMAP_ELT_BITS ((unsigned) HOST_BITS_PER_LONG)
+#define SBITMAP_ELT_TYPE unsigned long
+#else
 #define SBITMAP_ELT_BITS ((unsigned) HOST_BITS_PER_WIDE_INT)
 #define SBITMAP_ELT_TYPE unsigned HOST_WIDE_INT
+#endif
 
 typedef struct simple_bitmap_def
 {

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Paolo Bonzini]

 > Anybody can add their host
> to the list if this applies to them, I think sparc and/or mips but I
> do not know enough about thier code generation to add them.

I think that sbitmap could unconditionally use unsigned long.  Where it 
is efficient to have 64-bit integers, longs are most likely 64 bit integers.

Paolo

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Ian Lance Taylor]

Paolo Bonzini <bonzini@gnu.org> writes:

>  > Anybody can add their host
> > to the list if this applies to them, I think sparc and/or mips but I
> > do not know enough about thier code generation to add them.
> 
> I think that sbitmap could unconditionally use unsigned long.  Where
> it is efficient to have 64-bit integers, longs are most likely 64 bit
> integers.

I don't really agree with that, since systems often have a programming
mode in which longs are 32 bits even on a 64-bit system, just for
backward compatibility.

But I do think that the default in Andrew's patch should be to use
'unsigned long' on all systems, and specific systems should change
that default when appropriate.

Ian

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Segher Boessenkool]

>> I think that sbitmap could unconditionally use unsigned long.  Where
>> it is efficient to have 64-bit integers, longs are most likely 64 bit
>> integers.
>
> I don't really agree with that, since systems often have a programming
> mode in which longs are 32 bits even on a 64-bit system, just for
> backward compatibility.
>
> But I do think that the default in Andrew's patch should be to use
> 'unsigned long' on all systems, and specific systems should change
> that default when appropriate.

What would be a good name for this type...  HOST_FAST_INT perhaps?

Also, there is this comment in hwint.h:


/* Set HOST_WIDE_INT.  This should be the widest efficient host
    integer type.  It can be 32 or 64 bits, except that if we are
    targeting a machine with 64-bit size_t then it has to be 64 bits.

    With a sane ABI, 'long' is the largest efficient host integer type.
    Thus, we use that unless we have to use 'long long' or '__int64'
    because we're targeting a 64-bit machine from a 32-bit host.  */


I see no way a specific system can currently override this.
Should a mechanism for that be added, or should the comment
be changed?


Segher

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Segher Boessenkool]

> I think that sbitmap could unconditionally use unsigned long.  Where 
> it is efficient to have 64-bit integers, longs are most likely 64 bit 
> integers.

I think I sent a patch to do just that, long ago.

Either it wasn't reviewed or I completely forgot
to send it, or something else entirely.

My similar patch for bitmap.[ch] did go in.

I'll send patches for {s,}bitmap.[ch] incorporating
also Ian's suggestion.


Segher

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Ian Lance Taylor]

Segher Boessenkool <segher@kernel.crashing.org> writes:

> Also, there is this comment in hwint.h:
> 
> 
> /* Set HOST_WIDE_INT.  This should be the widest efficient host
>     integer type.  It can be 32 or 64 bits, except that if we are
>     targeting a machine with 64-bit size_t then it has to be 64 bits.
> 
>     With a sane ABI, 'long' is the largest efficient host integer type.
>     Thus, we use that unless we have to use 'long long' or '__int64'
>     because we're targeting a 64-bit machine from a 32-bit host.  */
> 
> 
> I see no way a specific system can currently override this.
> Should a mechanism for that be added, or should the comment
> be changed?

I think the comment is OK.  I don't think we need to override this.

We are looking for an integer which is fast even when targetting a
64-bit machine.  I think your suggestion of HOST_FAST_INT is
reasonable.  When targetting a 32-bit machine, HOST_FAST_INT and
HOST_WIDE_INT would normally be the same.  When targetting a 64-bit
machine, HOST_WIDE_INT must be 64 bits, but HOST_FAST_INT might be 32
bits.

There are popular targets which require a 64-bit HOST_WIDE_INT--
powerpc, mips, x86_64--so I think HOST_FAST_INT is a reasonable idea
to use in bitmap operations.

Ian

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Segher Boessenkool]

> I think the comment is OK.  I don't think we need to override this.

OK.

> We are looking for an integer which is fast even when targetting a
> 64-bit machine.  I think your suggestion of HOST_FAST_INT is
> reasonable.  When targetting a 32-bit machine, HOST_FAST_INT and
> HOST_WIDE_INT would normally be the same.  When targetting a 64-bit
> machine, HOST_WIDE_INT must be 64 bits, but HOST_FAST_INT might be 32
> bits.

So  (unsigned) long  will always work, you think?  Or does it need
a platform-specific override?  I can only think of 8- or 16-bit
host machines wanting that; and I don't really care about the speed
of compiling _on_ such a machine ;-)

> There are popular targets which require a 64-bit HOST_WIDE_INT--
> powerpc, mips, x86_64--so I think HOST_FAST_INT is a reasonable idea
> to use in bitmap operations.

That's what I did to speedup bitmap.[ch], but I hardcoded it to
unsigned long.  Will convert to HOST_FAST_INT and sbitmap too,
and whatever else I find (some register set stuff at least, I think).


Segher

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Ian Lance Taylor]

Segher Boessenkool <segher@kernel.crashing.org> writes:

> > We are looking for an integer which is fast even when targetting a
> > 64-bit machine.  I think your suggestion of HOST_FAST_INT is
> > reasonable.  When targetting a 32-bit machine, HOST_FAST_INT and
> > HOST_WIDE_INT would normally be the same.  When targetting a 64-bit
> > machine, HOST_WIDE_INT must be 64 bits, but HOST_FAST_INT might be 32
> > bits.
> 
> So  (unsigned) long  will always work, you think?  Or does it need
> a platform-specific override?  I can only think of 8- or 16-bit
> host machines wanting that; and I don't really care about the speed
> of compiling _on_ such a machine ;-)

My sense is that it should have a platform specific override not to
make it smaller, but to make it larger.  On a machine with 64-bit
registers, we want to use a 64-bit type, because the bitmap code will
(presumably) run faster.  Although many of those systems will have a
64-bit long, some will still use a 32-bit long.  So I think we should
have the capacity for an override to speed up the compiler in such a
case.

Ian

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Segher Boessenkool]

> My sense is that it should have a platform specific override not to
> make it smaller, but to make it larger.  On a machine with 64-bit
> registers, we want to use a 64-bit type, because the bitmap code will
> (presumably) run faster.  Although many of those systems will have a
> 64-bit long, some will still use a 32-bit long.  So I think we should
> have the capacity for an override to speed up the compiler in such a
> case.

Is there any such system supported by GCC right now?


Segher

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Andrew Pinski]

> 
> > My sense is that it should have a platform specific override not to
> > make it smaller, but to make it larger.  On a machine with 64-bit
> > registers, we want to use a 64-bit type, because the bitmap code will
> > (presumably) run faster.  Although many of those systems will have a
> > 64-bit long, some will still use a 32-bit long.  So I think we should
> > have the capacity for an override to speed up the compiler in such a
> > case.
> 
> Is there any such system supported by GCC right now?

The only system I can think of is WIN64 but I think it is not supported
by GCC yet.

Thanks,
Andrew Pinski

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Segher Boessenkool]

>> Is there any such system supported by GCC right now?
>
> The only system I can think of is WIN64 but I think it is not supported
> by GCC yet.

I'll just hard-code to 'long' for now, with an appropriate
comment.  If such a system ever shows up and people care
enough, they can create an override mechanism.  Anyway,
always using 'long' isn't worse than what we currently do
(HOST_WIDE_INT).


Segher

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Ian Lance Taylor]

Segher Boessenkool <segher@kernel.crashing.org> writes:

> > My sense is that it should have a platform specific override not to
> > make it smaller, but to make it larger.  On a machine with 64-bit
> > registers, we want to use a 64-bit type, because the bitmap code will
> > (presumably) run faster.  Although many of those systems will have a
> > 64-bit long, some will still use a 32-bit long.  So I think we should
> > have the capacity for an override to speed up the compiler in such a
> > case.
> 
> Is there any such system supported by GCC right now?

I believe this is true of Irix in n32 mode.

Ian

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Andreas Jaeger]

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

Segher Boessenkool <segher@kernel.crashing.org> writes:

>>> Is there any such system supported by GCC right now?
>>
>> The only system I can think of is WIN64 but I think it is not supported
>> by GCC yet.
>
> I'll just hard-code to 'long' for now, with an appropriate

I suggest to use a typedef or a macro instead of long - that way you
can change it later easily....

> comment.  If such a system ever shows up and people care
> enough, they can create an override mechanism.  Anyway,
> always using 'long' isn't worse than what we currently do
> (HOST_WIDE_INT).

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Richard Henderson]

On Fri, Jun 11, 2004 at 03:42:05PM +0200, Segher Boessenkool wrote:
> Is there any such system supported by GCC right now?

ia64-hpux.


r~

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Segher Boessenkool]

>> Is there any such system supported by GCC right now?
>
> ia64-hpux.

Okay...  so the ia64-hpux people can invent some way to
override it, if they care ;-)


Segher

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Segher Boessenkool]

>> I'll just hard-code to 'long' for now, with an appropriate
>
> I suggest to use a typedef or a macro instead of long - that way you
> can change it later easily....

Well I meant, I'll hardcode the new macro to be `long'...
No need for an extra extra level of indirection.


Segher

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Segher Boessenkool]

> I also moved the code to decide which type to use into hwint.h so other
> files can use it also if they want.  Also since ia64-hpux was mentioned
> as one of the targets where long long was more effiecent I turned it on
> for that host.
>
> OK? Bootstrapped on powerpc-apple-darwin with no regressions?

Really?  When I did a very similar patch last week (which I could not
contribute as none of my native targets have been bootstrapping on
mainline), I also needed a patch to gengtype-lex.l to recognize the
new HOST_FASTEST_INT type, or bootstrap would fail really early.


Segher

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Zack Weinberg]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> I decided to rename the configure option and make it default to use
> long instead of long long.  I also moved the code to decide which
> type to use into hwint.h so other files can use it also if they
> want.  Also since ia64-hpux was mentioned as one of the targets
> where long long was more effiecent I turned it on for that host.
>
> OK? Bootstrapped on powerpc-apple-darwin with no regressions?

I want a bunch of minor adjustments (mostly to commentary):

> 	* config.host (host_efficient_long_long): New, set defaultly to no.

        "New, default is off."

> 	And set to yes for ia64-*-hpux*.

        "(ia64-*-hpux*): Enable host_efficient_long_long."


> 	* hwint.h (HOST_FASTEST_INT): Define on the fastest integer type
> 	based on EFFICIENT_LONG_LONG.

"HOST_FASTEST_INT" is not a clear name for this.  Suggest
HOST_WIDEST_FAST_INT.

        (HOST_WIDEST_FAST_INT, HOST_BITS_PER_WIDEST_FAST_INT): 
        New: widest integer type supported efficiently in hardware for
        the host.

> 	* sbitmap.h (SBITMAP_ELT_BITS): Define based on HOST_BITS_PRE_FASTEST_INT.

        Typo: PER, not PRE.

> 	(SBITMAP_ELT_TYPE): Define base on HOST_FASTEST_INT.

        "based"

> +if test x$host_efficient_long_long = xyes; then
> +	AC_DEFINE(EFFICIENT_LONG_LONG, 1,
> +[Define to 1 if long long are efficient for general use.])
> +fi

This name and description are not very clear.  Suggest

  AC_DEFINE(USE_LONG_LONG_FOR_WIDEST_FAST_INT, 1,
  [Define to 1 if the 'long long' (or '__int64') type is wider 
   than 'long' but still efficiently supported by the host hardware.])

> +#  host_efficient_long_long Set to no normally; to no if long long are
> +#			 not as effiecient as long integers

Similarly,

#  use_long_long_for_widest_fast_int   Set this to 'yes' if 'long long'
#                                      (or '__int64') is wider than 'long'
#                                      but still efficiently supported
#                                      by the host hardware.  Only affects
#                                      compile speed.  Default is 'no'.
   
> +case ${host} in
> +  ia64-*-hpux*)
> +    host_efficient_long_long=yes
> +    ;;
> +esac

Don't create a new case statement just for this; put it in the main one.

> +#define SBITMAP_ELT_BITS ((unsigned) HOST_BITS_PRE_FASTEST_INT)

Same typo: PER, not PRE.

> +/* Set HOST_FASTEST_INT to the fastest and largest integer type available.  */

/* Define HOST_WIDEST_FAST_INT to the widest integer type supported
   efficiently in hardware.  (That is, the widest integer type that
   fits in a hardware register.)  Normally this is "long", but on
   some hosts it should be "long long" or "__int64".  There is no
   convenient way to autodetect this, so such systems must set a
   flag in config.host; see there for details.  */

> +  #error "This should be impossible to reach"

1) It is no longer necessary to indent the leading # of an #error.
2) Be specific.  "Have neither long long nor __int64 for HOST_WIDEST_FAST_INT".

I'm very likely to approve this if you make these changes, but I want
to see it once more first.

zw

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Andreas Jaeger]

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

Andrew Pinski <pinskia@physics.uc.edu> writes:

> I decided to rename the configure option and make it default to use long instead of long long.
> I also moved the code to decide which type to use into hwint.h so other
> files can use it also if they want.  Also since ia64-hpux was mentioned
> as one of the targets where long long was more effiecent I turned it on
> for that host.
> +#
> +#  host_efficient_long_long Set to no normally; to no if long long are
> +#			 not as effiecient as long integers

On most 64-bit systems long and long long are the same, this includes
ia64-hpux.  So, why is that setting usefull for ia64-hpux but not for
ia64-linux?  Should it be set for all 64-bit hosts - or is this not
needed if long = long long?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [PATCH] Fix PR 13987, compile time slow down on powerpc-apple-darwin

[Andrew Pinski]

I decided to rename the configure option and make it default to use long instead of long long.
I also moved the code to decide which type to use into hwint.h so other
files can use it also if they want.  Also since ia64-hpux was mentioned
as one of the targets where long long was more effiecent I turned it on
for that host.

OK? Bootstrapped on powerpc-apple-darwin with no regressions?

Thanks,
Andrew Pinski
ChangeLog:

	* config.host (host_efficient_long_long): New, set defaultly to no.
	And set to yes for ia64-*-hpux*.
	* configure.ac: If host_efficient_long_long, then define EFFICIENT_LONG_LONG.
	* configure: Regenerate.
	* config.in: Regenerate.
	* hwint.h (HOST_FASTEST_INT): Define on the fastest integer type
	based on EFFICIENT_LONG_LONG.
	* sbitmap.h (SBITMAP_ELT_BITS): Define based on HOST_BITS_PRE_FASTEST_INT.
	(SBITMAP_ELT_TYPE): Define base on HOST_FASTEST_INT.


Index: configure.ac
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.ac,v
retrieving revision 2.43
diff -u -p -r2.43 configure.ac
--- configure.ac	18 Jun 2004 01:59:45 -0000	2.43
+++ configure.ac	19 Jun 2004 18:55:31 -0000
@@ -1170,6 +1170,11 @@ if test x$need_64bit_hwint = xyes; then
 [Define to 1 if HOST_WIDE_INT must be 64 bits wide (see hwint.h).])
 fi
 
+if test x$host_efficient_long_long = xyes; then
+	AC_DEFINE(EFFICIENT_LONG_LONG, 1,
+[Define to 1 if long long are efficient for general use.])
+fi
+
 count=a
 for f in $host_xm_file; do
 	count=${count}x
Index: config.host
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config.host,v
retrieving revision 2.10
diff -u -p -r2.10 config.host
--- config.host	5 Jun 2004 07:28:25 -0000	2.10
+++ config.host	19 Jun 2004 18:55:31 -0000
@@ -52,6 +52,9 @@
 #
 #  host_can_use_collect2 Set to yes normally; to no if the host cannot
 #			link or otherwise use collect2
+#
+#  host_efficient_long_long Set to no normally; to no if long long are
+#			 not as effiecient as long integers
 
 # When setting any of these variables, check to see if a corresponding
 # variable is present in config.build; if so, you will likely want to 
@@ -66,6 +69,7 @@ host_extra_objs=
 host_extra_gcc_objs=
 out_host_hook_obj=host-default.o
 host_can_use_collect2=yes
+host_efficient_long_long=no
 
 # Unsupported hosts list.  Generally, only include hosts known to fail here,
 # since we allow hosts not listed to be supported generically.
@@ -80,6 +84,12 @@ case ${host} in
     ;;
 esac
 
+case ${host} in
+  ia64-*-hpux*)
+    host_efficient_long_long=yes
+    ;;
+esac
+
 # Machine-specific settings.
 case ${host} in
   alpha*-dec-*vms*)
Index: sbitmap.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/sbitmap.h,v
retrieving revision 1.21
diff -u -p -r1.21 sbitmap.h
--- sbitmap.h	13 May 2004 06:39:45 -0000	1.21
+++ sbitmap.h	19 Jun 2004 18:55:31 -0000
@@ -25,8 +25,9 @@ Software Foundation, 59 Temple Place - S
    It should be straightforward to convert so for now we keep things simple
    while more important issues are dealt with.  */
 
-#define SBITMAP_ELT_BITS ((unsigned) HOST_BITS_PER_WIDE_INT)
-#define SBITMAP_ELT_TYPE unsigned HOST_WIDE_INT
+
+#define SBITMAP_ELT_BITS ((unsigned) HOST_BITS_PRE_FASTEST_INT)
+#define SBITMAP_ELT_TYPE unsigned HOST_FASTEST_INT
 
 typedef struct simple_bitmap_def
 {
Index: hwint.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/hwint.h,v
retrieving revision 1.17
diff -u -p -r1.17 hwint.h
--- hwint.h	25 Jun 2003 19:33:08 -0000	1.17
+++ hwint.h	19 Jun 2004 18:55:31 -0000
@@ -116,4 +116,21 @@ extern char sizeof_long_long_must_be_8[s
 # define HOST_WIDEST_INT_PRINT_DOUBLE_HEX     "0x%llx%016llx"
 #endif
 
+/* Set HOST_FASTEST_INT to the fastest and largest integer type available.  */
+
+#ifdef EFFICIENT_LONG_LONG
+# ifdef HAVE_LONG_LONG
+#  define HOST_FASTEST_INT long long
+#  define HOST_BITS_PRE_FASTEST_INT HOST_BITS_PER_LONGLONG
+# elif defined (HAVE___INT64)
+#  define HOST_FASTEST_INT __int64
+#  define HOST_BITS_PRE_FASTEST_INT HOST_BITS_PER___INT64
+# else
+  #error "This should be impossible to reach"
+#endif
+#else
+# define HOST_FASTEST_INT long
+# define HOST_BITS_PRE_FASTEST_INT HOST_BITS_PER_LONG
+#endif
+
 #endif /* ! GCC_HWINT_H */