ppc-linux and s390-linux compilers requiring 64-bit HWI?
Hi!
What's the reason why ppc-linux and s390-linux targetted GCC
requires 64-bit HWI these days?
If it is a native compiler, this means using long long in a huge part
of the compiler and therefore slower compile times and bigger memory
consumption.
ppc-linux configured compiler (nor s390-linux) isn't multilibbed and
ppc-linux only supports -m32 (s390-linux one apparently supports
both -m31 and -m64 on the GCC side, but without multilibs it isn't very
helpful).
Say i386 or sparc-linux which also only support -m32 don't require 64-bit
HWI, while if you target x86_64 or sparc64-linux which support both -m32
and -m64 obviously 64-bit HWI is required.
--- libcpp/configure.ac.jj 2005-10-28 23:13:40.0 +0200
+++ libcpp/configure.ac 2005-11-25 14:34:31.0 +0100
@@ -112,6 +112,8 @@ fi
m4_changequote(,)
case $target in
+ powerpc-*-linux*)
+ need_64bit_hwint=no ;;
alpha*-*-* | \
arm*-*-*eabi* | \
arm*-*-symbianelf* | \
@@ -123,7 +125,7 @@ case $target in
mmix-*-* | \
powerpc*-*-* | \
rs6000*-*-* | \
- s390*-*-* | \
+ s390x-*-* | \
sparc64*-*-* | ultrasparc-*-freebsd* | \
sparcv9-*-solaris2* | \
sparc-*-solaris2.[789] | sparc-*-solaris2.1[0-9]* | \
--- libcpp/configure.jj 2005-10-28 23:13:40.0 +0200
+++ libcpp/configure2005-11-25 14:34:40.0 +0100
@@ -8217,6 +8217,8 @@ fi
case $target in
+ powerpc-*-linux*)
+ need_64bit_hwint=no ;;
alpha*-*-* | \
arm*-*-*eabi* | \
arm*-*-symbianelf* | \
@@ -8228,7 +8230,7 @@ case $target in
mmix-*-* | \
powerpc*-*-* | \
rs6000*-*-* | \
- s390*-*-* | \
+ s390x-*-* | \
sparc64*-*-* | ultrasparc-*-freebsd* | \
sparcv9-*-solaris2* | \
sparc-*-solaris2.[789] | sparc-*-solaris2.1[0-9]* | \
--- gcc/config.gcc.jj 2005-11-19 09:27:16.0 +0100
+++ gcc/config.gcc 2005-11-25 14:29:30.0 +0100
@@ -294,7 +294,10 @@ mips*-*-*)
powerpc*-*-*)
cpu_type=rs6000
extra_headers="ppc-asm.h altivec.h spe.h"
- need_64bit_hwint=yes
+ case ${target} in
+ powerpc-*-linux*) ;;
+ *) need_64bit_hwint=yes ;;
+ esac
case x$with_cpu in
xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[345]|xrs64a)
cpu_is_64bit=yes
@@ -311,10 +314,13 @@ sparc64*-*-*)
sparc*-*-*)
cpu_type=sparc
;;
-s390*-*-*)
+s390x-*-*)
cpu_type=s390
need_64bit_hwint=yes
;;
+s390*-*-*)
+ cpu_type=s390
+ ;;
# Note the 'l'; we need to be able to match e.g. "shle" or "shl".
sh[123456789lbe]*-*-*)
cpu_type=sh
Jakub
Re: ppc-linux and s390-linux compilers requiring 64-bit HWI?
> > Hi! > > What's the reason why ppc-linux and s390-linux targetted GCC > requires 64-bit HWI these days? > If it is a native compiler, this means using long long in a huge part > of the compiler and therefore slower compile times and bigger memory > consumption. powerpc-linux supports -mpowerpc64 (or at least will once the kernel is fixed). I think you should do timings and show mememory uage because I and others have fixed almost all of these issues. Thanks, Andrew Pinski
Re: ppc-linux and s390-linux compilers requiring 64-bit HWI?
On Sat, Nov 26, 2005 at 03:38:18AM -0500, Jakub Jelinek wrote: > What's the reason why ppc-linux and s390-linux targetted GCC > requires 64-bit HWI these days? Be careful with ppc; altivec may need hwi 64bit. r~
Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)
On Nov 22, 2005, at 7:52 AM, Richard Earnshaw wrote: 3) A volatile load isn't moved across any store that may alias (though I'd expect that to be volatile if there's a real risk of aliasning, so maybe we could have another dimension in the 'may-alias' test here). ? Is this just a restatement of the general rule that one cannot move a load across a store that may alias? If so, we don't need to list it here, as it comes under the normal rules of what one may not do, and sense we don't relist all of them, there isn't any point in listing any of them.
Re: Why doesn't combine like volatiles? (volatile_ok again, sorry!)
On Nov 22, 2005, at 8:10 AM, Robert Dewar wrote: I think this is a bad idea in practice, since volatile will be used to describe memory mapped devices, and combining can completely mess up the access. Only if one missed a restriction.
Re: Would Like to Contribute, Where to Start?
On Nov 25, 2005, at 9:49 AM, Michael Garvin wrote: I would like to jump in and start contributing, Welcome aboard. but I'm wondering if I need to create a designer account anywhere, or join the project electronicly? Things you need to do, file paper work if you want to contribute anything more than a few lines and send patches to gcc-patches. :-) Most everything else is optional. I wouldn't know what a designer account is if it hit me, is it anything like a designer handbag? As far as joining, there isn't anything to join, unless you want to subscribe to the mainling lists (gcc, gcc-patches come to mind). Is there a more current list of beginner projects? Nope. The web site and wiki pages are updated all the time. I was just thinking the beginner stuff would be a good way to get started. Anyways, if there is still some of that work left to do, let me know what I should do procedure wise before jumping in. http://gcc.gnu.org/contribute.html Just pick something and jump in.
Re: Thoughts on LLVM and LTO
On Nov 23, 2005, at 10:30 AM, Diego Novillo wrote: I'll keep an eye on the apple branch. Will gfortran work on the branch? I generally like to keep Java and Fortran working on it. For moments in time, it can have various breakages, though, they tend to be obvious/trivial to fix. For some reason, I think it is currently broken, but, I could just be misremembering.
