This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]