Digital Mars - D.gnu - GDC Release

↑ ↓ ← → Benjamin Herr <ben 0x539.de> writes:

Hoi,

this is a kind of a transcript of my attempts to compile a hello world D 
program with gdc. >-prefixed lines give console input and output, the 
other lines are my comments, obviously

I use Gentoo, so I installed gdc by emerge'ing gcc-3.4.2, stopped it 
before it started to compile, added the gdc directory, applied the 
patches and changed the gcc-related ebuilds to know about the D frontend.

 $ uname -a
 Linux oreichalkon 2.6.8-gentoo-r4 #1 Fri Sep 24 19:46:07 CEST 2004 


 $ cat foo.d
 int main() {
	printf("Hallo\n");
	return 0;
 }
 $ gdc -o foo foo.d
 cc1d: 


Lexer::number(Token*): Assertion `sizeof(long) == 4' failed.
 foo.d:0: internal compiler error: Aborted


   I  changed to assert(sizeof(long >= 4);

 gdc -o foo foo.d
 /usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.2/cc1d: error while loading 


such file or directory

 $ gdc -o foo foo.d
 /usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.2/cc1d: error while loading 


file or directory

   Both times the libs were in /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/ 
but according to strace, only /lib64/tls/x86_64, /lib64/x86_64, /lib64, 
/usr/lib64/tls/x86_64, /usr/lib64/x86_64, /usr/lib64/ were checked.
   I added symlinks in /usr/lib64 because I was too lazy to figure out 
how to do this correctly, or what I broke in first place.


 $ gdc -o foo foo.d
 


C style cast deprecated, use cast(void*)(this)

   ... and many more such warnings.
   object.d was casting this-pointers and object references to 
void-pointers and then to int. I fixed the (foo) casts to cast(foo), and 
replaced int and uint with ptrdiff_t and size_t respectively; however we 
need to come up with a better Object#toHash than converting `this' to an 
int, as int.sizeof < (void*).sizeof. Also, it might make sense to define 
opCmp as
   int opCmp(Object other) {
     void* t = cast(void *)this, o = cast(void *)other;
     return t == o ? 0 : t < o ? -1 : t > o ? 1 : (assert(false), 0);
   }
   A diff is at http://ilfirin.org/object.d.diff

 d $ gdc -o foo foo.d
 d $ ./foo
 Hallo
 Segmentation fault


   gdb reveals:
   Program received signal SIGSEGV, Segmentation fault.
   _moduleDtor () at ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit.d:162
   162     ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit.d: No such file 
or directory.
           in ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit

   I realise I forgot to rebuild phobos *cough*, although this error 
already happened last time with the 1f release and correctly built phobos.
   So I tried to compile phobos.
   There is a problem with phobos' configure passing 'CC=gcc' 'CXX=g++' 
to boehm-gc's configure, which it interprets as target hosts:
   > configure: warning: CC=gcc: invalid host type
   > configure: warning: CXX=g++: invalid host type
   > configure: error: can only configure for one host and one target at 
a time
   > configure: error: /bin/sh 
'../../../gcc-3.4.2/gcc/d/phobos/boehm-gc/configure' failed for boehm-gc
   I had a hacky Ruby script strip non-options from the command line

   > # make
   > gcc -o config/gen_unix.o -g -O2 -DPHOBOS_USE_PTHREADS=1 
-DHAVE_CONFIG_H -I etc/c/stlsoft -I . -c 
/var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/config/gen_unix.c
   > gcc -o gen_unix config/gen_unix.o
   > ./gen_unix > frag-unix
   > /bin/sh: line 1:  2060 Segmentation fault      ./gen_unix >frag-unix
   > make: *** [frag-unix] Error 139
   gdb says 0x0000000000402843 in __PRETTY_FUNCTION__.0 ()
   I ended up using the output produced until the segfault and adding 
the rest manually.

   > cc1d: 
/var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/dmd/toobj.c:252: 
virtual void ClassDeclaration::toObjFile(): Assertion 
`classinfo->structsize == 0x3C' failed.
   > 
/var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/std/asserterror.d: 
In function `_ctor':
   > 
/var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/std/asserterror.d:42: 
internal compiler error: Aborted
   Assumption that (void*).sizeof and a reference's size is 4, and a 
dynamic array's size is 8.
   I changed the #define'ition of CLASSINFO_SIZE from 0x3c to 
sizeof(void*)*2 * 4 + sizeof(void*)*4 + sizeof(int) in aggregate.h:197.
   Trying to recompile gdc, it does not find libgcc_s.so. I must have 
broken it somewhere above; I added another symlink and started compiling 
again.
   Now I do not have enough time until I have to leave for four more 
hours of school, so I will just post this now and continue trying after 
school.


I greatly appreciate the effort you have already put into this project, 
and hope that my data is of use. I will certainly try to fix more issues 
as I come across them, and I will report them.

I hope that Walter will make his part of the frontend less dependant on 
machine word sizes so porting will be easier.

   -ben

Oct 04 2004

↑ ↓ ← → David Friedman <d3rdclsmail earthlink.net> writes:

nowBenjamin Herr wrote:
 Hoi,

 this is a kind of a transcript of my attempts to compile a hello world D 
 program with gdc. >-prefixed lines give console input and output, the 
 other lines are my comments, obviously

 I use Gentoo, so I installed gdc by emerge'ing gcc-3.4.2, stopped it 
 before it started to compile, added the gdc directory, applied the 
 patches and changed the gcc-related ebuilds to know about the D frontend.

  > $ uname -a
  > Linux oreichalkon 2.6.8-gentoo-r4 #1 Fri Sep 24 19:46:07 CEST 2004 
 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
  > $ cat foo.d
  > int main() {
  >    printf("Hallo\n");
  >    return 0;
  > }
  > $ gdc -o foo foo.d
  > cc1d: 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/dmd/lexer.c:1533: TOK 
 Lexer::number(Token*): Assertion `sizeof(long) == 4' failed.
  > foo.d:0: internal compiler error: Aborted

   I  changed to assert(sizeof(long >= 4);

  > gdc -o foo foo.d
  > /usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.2/cc1d: error while loading 
 shared libraries: libstdc++.so.6: cannot open shared object file: No 
 such file or directory

  > $ gdc -o foo foo.d
  > /usr/libexec/gcc/x86_64-pc-linux-gnu/3.4.2/cc1d: error while loading 
 shared libraries: libgcc_s.so.1: cannot open shared object file: No such 
 file or directory

   Both times the libs were in /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.1/ 
 but according to strace, only /lib64/tls/x86_64, /lib64/x86_64, /lib64, 
 /usr/lib64/tls/x86_64, /usr/lib64/x86_64, /usr/lib64/ were checked.
   I added symlinks in /usr/lib64 because I was too lazy to figure out 
 how to do this correctly, or what I broke in first place.

  > $ gdc -o foo foo.d
  > 
 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/../../../../include/d/object.d(32): 
 C style cast deprecated, use cast(void*)(this)

   ... and many more such warnings.
   object.d was casting this-pointers and object references to 
 void-pointers and then to int. I fixed the (foo) casts to cast(foo), and 
 replaced int and uint with ptrdiff_t and size_t respectively; however we 
 need to come up with a better Object#toHash than converting `this' to an 
 int, as int.sizeof < (void*).sizeof. Also, it might make sense to define 
 opCmp as
   int opCmp(Object other) {
     void* t = cast(void *)this, o = cast(void *)other;
     return t == o ? 0 : t < o ? -1 : t > o ? 1 : (assert(false), 0);
   }
   A diff is at http://ilfirin.org/object.d.diff

  > d $ gdc -o foo foo.d
  > d $ ./foo
  > Hallo
  > Segmentation fault

   gdb reveals:
   Program received signal SIGSEGV, Segmentation fault.
   _moduleDtor () at ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit.d:162
   162     ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit.d: No such file or 
 directory.
           in ../../gcc-3.4.1/gcc/d/phobos/std/moduleinit

   I realise I forgot to rebuild phobos *cough*, although this error 
 already happened last time with the 1f release and correctly built phobos.
   So I tried to compile phobos.
   There is a problem with phobos' configure passing 'CC=gcc' 'CXX=g++' 
 to boehm-gc's configure, which it interprets as target hosts:
   > configure: warning: CC=gcc: invalid host type
   > configure: warning: CXX=g++: invalid host type
   > configure: error: can only configure for one host and one target at 
 a time
   > configure: error: /bin/sh 
 '../../../gcc-3.4.2/gcc/d/phobos/boehm-gc/configure' failed for boehm-gc
   I had a hacky Ruby script strip non-options from the command line

   > # make
   > gcc -o config/gen_unix.o -g -O2 -DPHOBOS_USE_PTHREADS=1 
 -DHAVE_CONFIG_H -I etc/c/stlsoft -I . -c 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/config/gen_unix.c
   > gcc -o gen_unix config/gen_unix.o
   > ./gen_unix > frag-unix
   > /bin/sh: line 1:  2060 Segmentation fault      ./gen_unix >frag-unix
   > make: *** [frag-unix] Error 139
   gdb says 0x0000000000402843 in __PRETTY_FUNCTION__.0 ()
   I ended up using the output produced until the segfault and adding the 
 rest manually.

   > cc1d: 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/dmd/toobj.c:252: 
 virtual void ClassDeclaration::toObjFile(): Assertion 
 `classinfo->structsize == 0x3C' failed.
   > 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/std/asserterror.d: 
 In function `_ctor':
   > 
 /var/tmp/portage/gcc-3.4.2-r2/work/gcc-3.4.2/gcc/d/phobos/s
d/asserterror.d:42: 
 internal compiler error: Aborted
   Assumption that (void*).sizeof and a reference's size is 4, and a 
 dynamic array's size is 8.
   I changed the #define'ition of CLASSINFO_SIZE from 0x3c to 
 sizeof(void*)*2 * 4 + sizeof(void*)*4 + sizeof(int) in aggregate.h:197.
   Trying to recompile gdc, it does not find libgcc_s.so. I must have 
 broken it somewhere above; I added another symlink and started compiling 
 again.
   Now I do not have enough time until I have to leave for four more 
 hours of school, so I will just post this now and continue trying after 
 school.

 I greatly appreciate the effort you have already put into this project, 
 and hope that my data is of use. I will certainly try to fix more issues 
 as I come across them, and I will report them.

 I hope that Walter will make his part of the frontend less dependant on 
 machine word sizes so porting will be easier.

   -ben

Thanks for trying it out!  I guess my own code isn't 64-bit clean 
(gen_unix crash.)

The shared library error is similar to what I got when I tried to do a 
bootstrap build -- the C++ executables become dependent on the new 
libraries which are not yet installed.  Once installed, though, you can 
set the LD_LIBRARY_PATH environment variable.

For building Phobos, I usually just change the PATH so that gdc and the 
same-version C and C++ compilers are the default and I don't have to do 
anything special for the configure script.  If you do this, remember to 
use the original system compiler to rebuild gdc.

BTW, if you want to try out the compiler without Phobos, you can compile 
with -fno-exceptions and use a C-style main (i.e, extern(C) int 
main(int, char**) {...}).  This severely limits what you can do, but at 
least you can make executables.

David

Oct 04 2004

↑ ↓ ← → Benjamin Herr <ben 0x539.de> writes:

David Friedman wrote:
 Thanks for trying it out!  I guess my own code isn't 64-bit clean 
 (gen_unix crash.)


I have no idea how that piece of code could crash, and I would rather 
blame it on some messup on my side instead of your code.

 The shared library error is similar to what I got when I tried to do a 
 bootstrap build -- the C++ executables become dependent on the new 
 libraries which are not yet installed.  Once installed, though, you can 
 set the LD_LIBRARY_PATH environment variable.



 For building Phobos, I usually just change the PATH so that gdc and the 
 same-version C and C++ compilers are the default and I don't have to do 
 anything special for the configure script.  If you do this, remember to 
 use the original system compiler to rebuild gdc.


compile all this, and I did not attempt to do anything special. I do not 
think I did anything to cause the configure script to put these strange 
parameters, assuming that is what you are referring to.

 BTW, if you want to try out the compiler without Phobos, you can compile 
 with -fno-exceptions and use a C-style main (i.e, extern(C) int 
 main(int, char**) {...}).  This severely limits what you can do, but at 
 least you can make executables.


on my system, so I can indeed play around a bit already.
But thanks for the hint, as this will probably need to non-segfaulting 
executables :)

Slightly updated transcript, up to the point where I am now stuck: 
http://ilfirin.org/gdc
Note that my previous attempt to redefine CLASSINFO_SIZE was wrong, and 
the current one is more or less based on coincidence as I have no clue 
what a monitor_t is.

-ben

Oct 04 2004

↑ ↓ ← → David Friedman <d3rdclsmail earthlink.net> writes:

Benjamin Herr wrote:
 David Friedman wrote:
 
 Thanks for trying it out!  I guess my own code isn't 64-bit clean 
 (gen_unix crash.)


 Thanks for allowing me to try it out :)
 I have no idea how that piece of code could crash, and I would rather 
 blame it on some messup on my side instead of your code.
 


Ah, but did I did find a bug -- used a '%d' format with a ptrdiff_t 
argument.

 The shared library error is similar to what I got when I tried to do a 
 bootstrap build -- the C++ executables become dependent on the new 
 libraries which are not yet installed.  Once installed, though, you 
 can set the LD_LIBRARY_PATH environment variable.


 Meh, it works like this.
 
 For building Phobos, I usually just change the PATH so that gdc and 
 the same-version C and C++ compilers are the default and I don't have 
 to do anything special for the configure script.  If you do this, 
 remember to use the original system compiler to rebuild gdc.


 I do indeed use the original system compiler which now features gdc to 
 compile all this, and I did not attempt to do anything special. I do not 
 think I did anything to cause the configure script to put these strange 
 parameters, assuming that is what you are referring to.
 


Now that you mention it, I think I saw this before.  I can't remember 
what the cause was.

 BTW, if you want to try out the compiler without Phobos, you can 
 compile with -fno-exceptions and use a C-style main (i.e, extern(C) 
 int main(int, char**) {...}).  This severely limits what you can do, 
 but at least you can make executables.


 I actually still have a semi-working phobos installation from release 1f 
 on my system, so I can indeed play around a bit already.
 But thanks for the hint, as this will probably need to non-segfaulting 
 executables :)
 
 Slightly updated transcript, up to the point where I am now stuck: 
 http://ilfirin.org/gdc
 Note that my previous attempt to redefine CLASSINFO_SIZE was wrong, and 
 the current one is more or less based on coincidence as I have no clue 
 what a monitor_t is.
 
 -ben


The monitor field is a pointer to a platform-specific synchronization 
object.

I'll check out the updated transcript.

David

Oct 04 2004

↑ ↓ ← → Dave <Dave_member pathlink.com> writes:

<posted & mailed>

David Friedman wrote:

 teqDruid wrote:
 David (or anyone else capable of doing it), are you planning on releasing
 an updated GDC anytime soon?  My program uses features introduced in
 0.99, so it don't work too well with GDC.
 
 Thanks
 John


 GDC is synched up to DMD 0.102 and am I now regression testing.  If
 there are no serious setbacks, I will release a new version this weekend.
 
 David


David - thanks for all of your work on this!!

I would like to suggest a couple of changes to the default D -> GCC compiler
option mappings:

(In decending order of importance)

-O implies -fno-bounds-check by default
-O implies -fomit-frame-pointer
-O implies -fweb and -fgcse-after-reload
-O implies -mcpu=pentium4 (>= 3.4.x: -mtune=pentium4)
Also add the -funroll-loops option.

Rationale (sorry, this gets a bit long):

The DMD 'reference compiler' turns off bounds checking with -0 and of course
this can really make a large difference. From my understanding in following
the NG threads it's pretty well accepted and understood by D users that -O
will do this.

-fomit-frame-pointer is something that (I've read) the GCC group has been
discussing making implied for x86 with any -O option in coming versions of
GCC (The docs. for <= 3.4.x said it was implied by -O[n] for x86 but it
turns out it actually isn't currently..). D code should not have the legacy
debugging issues to deal with and from what I've seen this switch can make
a big difference in code speed where a lot of functions are being called.

-fweb and -fgcse-after-reload.. Along with the -inline switch, this will
bring the optimization up to '-O3' levels. I've used -O3 to good effect for
a couple of production executables and seen it make a big difference in
benchmarks as well - I've also never seen it degrade performance. I'm
seeing a number of make files starting to use this option.

-mtune=pentium4 - Can make a sizeable difference for P4 while not really
effecting < P4 machines. Of course, the most performance intensive
applications will be run on P4 class machines.

Unroll loops - GCC seems to be getting pretty good at this and I've seen it
make a difference in production code with GCC >= 3.3.x.

The overall rationale for these changes is simply to make sure the GCC
implementation of D puts its 'best foot' forward so D doesn't get
needlessly/unfairly tagged with performance issues that can be avoided with
default -O swtiches.

I've noticed that many of the 'GCC vs X' benchmarks out there for which GCC
does poorly are often due to /not/ applying the (perfectly legimate) -O3
and -fomit-frame-pointer switches. Besides, the 'competition' from Intel,
MS, etc.. generally optimize with levels comparable to -O3 with any of
their default 'for speed' switches.

If there is some regression testing or something that I could help with
if/when these changes are made, I'd be glad to do what I can..

Thanks,

- Dave

Sep 30 2004

↑ ↓ ← → David Friedman <d3rdclsmail earthlink.net> writes:

Dave wrote:
 <posted & mailed>
 
 David Friedman wrote:
 
 
teqDruid wrote:

David (or anyone else capable of doing it), are you planning on releasing
an updated GDC anytime soon?  My program uses features introduced in
0.99, so it don't work too well with GDC.

Thanks
John


GDC is synched up to DMD 0.102 and am I now regression testing.  If
there are no serious setbacks, I will release a new version this weekend.

David


 
 David - thanks for all of your work on this!!
 
 I would like to suggest a couple of changes to the default D -> GCC compiler
 option mappings:
 
 (In decending order of importance)
 
 -O implies -fno-bounds-check by default
 -O implies -fomit-frame-pointer
 -O implies -fweb and -fgcse-after-reload
 -O implies -mcpu=pentium4 (>= 3.4.x: -mtune=pentium4)
 Also add the -funroll-loops option.
 
 Rationale (sorry, this gets a bit long):
 
 The DMD 'reference compiler' turns off bounds checking with -0 and of course
 this can really make a large difference. From my understanding in following
 the NG threads it's pretty well accepted and understood by D users that -O
 will do this.
 
 -fomit-frame-pointer is something that (I've read) the GCC group has been
 discussing making implied for x86 with any -O option in coming versions of
 GCC (The docs. for <= 3.4.x said it was implied by -O[n] for x86 but it
 turns out it actually isn't currently..). D code should not have the legacy
 debugging issues to deal with and from what I've seen this switch can make
 a big difference in code speed where a lot of functions are being called.
 
 -fweb and -fgcse-after-reload.. Along with the -inline switch, this will
 bring the optimization up to '-O3' levels. I've used -O3 to good effect for
 a couple of production executables and seen it make a big difference in
 benchmarks as well - I've also never seen it degrade performance. I'm
 seeing a number of make files starting to use this option.
 
 -mtune=pentium4 - Can make a sizeable difference for P4 while not really
 effecting < P4 machines. Of course, the most performance intensive
 applications will be run on P4 class machines.
 
 Unroll loops - GCC seems to be getting pretty good at this and I've seen it
 make a difference in production code with GCC >= 3.3.x.
 
 The overall rationale for these changes is simply to make sure the GCC
 implementation of D puts its 'best foot' forward so D doesn't get
 needlessly/unfairly tagged with performance issues that can be avoided with
 default -O swtiches.
 
 I've noticed that many of the 'GCC vs X' benchmarks out there for which GCC
 does poorly are often due to /not/ applying the (perfectly legimate) -O3
 and -fomit-frame-pointer switches. Besides, the 'competition' from Intel,
 MS, etc.. generally optimize with levels comparable to -O3 with any of
 their default 'for speed' switches.
 
 If there is some regression testing or something that I could help with
 if/when these changes are made, I'd be glad to do what I can..
 
 Thanks,
 
 - Dave
 


Dave,

-fweb and -fomit-frame-pointer: I'll add these (along with 
-frename-registers).
-fgcse-after-reload: does not seem to be in recent GCC versions.
-mtune and -funroll-loops: I need to do some checking on these...

What was the reference for -O turning off bounds checking?  I made a 
quick test of bounds checking with -O and I still got an ArrayBoundsError.

FYI, anyone comparing GCC to DMD is going to see GCC lagging behind a 
bit as there are some x86 optimizations that require extra coding.  I 
still need to make D linkage functions use the same calling conventions 
as DMD (effectively, -mregparm=1 and -freg-struct-return.)

David

Oct 01 2004

↑ ↓ ← → Dave <Dave_member pathlink.com> writes:

David Friedman wrote:

 Dave wrote:
 <posted & mailed>




 


 Dave,
 
 -fweb and -fomit-frame-pointer: I'll add these (along with
 -frename-registers).
 -fgcse-after-reload: does not seem to be in recent GCC versions.
 -mtune and -funroll-loops: I need to do some checking on these...
 
 What was the reference for -O turning off bounds checking?  I made a
 quick test of bounds checking with -O and I still got an ArrayBoundsError.


Oops, sorry - for DMD, ArrayBoundsChecking is removed with '-release', not
'-O'.

Since GDC offers -f[no-]bounds-check seperately, I guess I assumed that
bounds checking is controlled independently of other switch(es).

I don't have a machine available right now to install GDC and give this a
shot myself.. If '-release' already implies -fno-bounds-check please
disregard.

Thanks again,

- Dave

 
 FYI, anyone comparing GCC to DMD is going to see GCC lagging behind a
 bit as there are some x86 optimizations that require extra coding.  I
 still need to make D linkage functions use the same calling conventions
 as DMD (effectively, -mregparm=1 and -freg-struct-return.)
 
 David

Oct 02 2004

↑ ↓ ← → David Friedman <d3rdclsmail earthlink.net> writes:

Dave wrote:
 David Friedman wrote:
 
 
Dave wrote:

<posted & mailed>




 [snip]
 
Dave,

-fweb and -fomit-frame-pointer: I'll add these (along with
-frename-registers).
-fgcse-after-reload: does not seem to be in recent GCC versions.
-mtune and -funroll-loops: I need to do some checking on these...

What was the reference for -O turning off bounds checking?  I made a
quick test of bounds checking with -O and I still got an ArrayBoundsError.


 
 Oops, sorry - for DMD, ArrayBoundsChecking is removed with '-release', not
 '-O'.
 
 Since GDC offers -f[no-]bounds-check seperately, I guess I assumed that
 bounds checking is controlled independently of other switch(es).
 
 I don't have a machine available right now to install GDC and give this a
 shot myself.. If '-release' already implies -fno-bounds-check please
 disregard.


It does.  I implemented -fbounds-check because it is actually defined as 
  a common option across all GCC compilers.  It's interesting 
considering that the most popular languages don't use it!

David

 
 Thanks again,
 
 - Dave
 
 
FYI, anyone comparing GCC to DMD is going to see GCC lagging behind a
bit as there are some x86 optimizations that require extra coding.  I
still need to make D linkage functions use the same calling conventions
as DMD (effectively, -mregparm=1 and -freg-struct-return.)

David

Oct 02 2004

↑ ↓ ← → David Friedman <d3rdclsmail earthlink.net> writes:

Dave wrote:
David Friedman wrote:


Dave,

-fweb and -fomit-frame-pointer: I'll add these (along with
-frename-registers).
-fgcse-after-reload: does not seem to be in recent GCC versions.
-mtune and -funroll-loops: I need to do some checking on these...


 
 You were right to question the -mtune=pentium4 and I was a little hasty to
 suggest it..
 
 Simply issuing this switch by default would have actually stopped the
 compilation on non-intel/amd (or AMD64 in 64 bit mode) machines. I should
 have considered that and maybe other potential issues with the switch more
 carefully..
 
 Would it be feasible/acceptable to allow -mcpu/-mtune as a pass-through type
 of option in some later release?
 
 I see you made the -O3 related changes to the 1g release - Thanks!
 
 - Dave
 


I planned to check for x86 first, but I didn't feel comfortable enabling 
'tradeoff' options by default.

The -mxxx options should already work (both dmd and gdc commands).

David

Oct 04 2004

↑ ↓ ← → Ilya Minkov <minkov cs.tum.edu> writes:

Dave schrieb:

 -mtune=pentium4 - Can make a sizeable difference for P4 while not really
 effecting < P4 machines. Of course, the most performance intensive
 applications will be run on P4 class machines.


Really? Call me oldskool, i have learned to prefer Pentium (P5, some 
people call them i586) tunings on x86. This is a significant boost on 
the original Pentium because it makes use of 2 pipelines by pairing the 
instructions, and Pentium Pro (P6, some people call them i686) specific 
tuning didn't bring much compared to that on P6 machines, but there was 
a significant adverse effect on P5. Reason is key novelty of P6 
architecture: three pipelines are symmetric and execute in parallel and 
out-of-order without too strict special conditions, while for P5 the 
opcodes must explicitly "pair".

What kind of tuning is done for Pentium 4? Why do you think it doesn't 
adversely affect performance on P6 and similar machines (Athlons and 
such)? I'm currently somewhat out-of-date, so i don't even know what 
kind of new optimizations Pentium 4 can apply or where new bottlenecks are.

BTW, the naming "P4" is problematic. You see why above. Is there any 
other short for it, or should i just get used to calling older systems 
i586/i686 instead of P5/P6?

-eye

Oct 03 2004

↑ ↓ ← → Dave <Dave_member pathlink.com> writes:

Ilya Minkov wrote:

 Dave schrieb:
 
 -mtune=pentium4 - Can make a sizeable difference for P4 while not really
 effecting < P4 machines. Of course, the most performance intensive
 applications will be run on P4 class machines.


 Really? Call me oldskool, i have learned to prefer Pentium (P5, some
 people call them i586) tunings on x86. This is a significant boost on
 the original Pentium because it makes use of 2 pipelines by pairing the
 instructions, and Pentium Pro (P6, some people call them i686) specific
 tuning didn't bring much compared to that on P6 machines, but there was
 a significant adverse effect on P5. Reason is key novelty of P6
 architecture: three pipelines are symmetric and execute in parallel and
 out-of-order without too strict special conditions, while for P5 the
 opcodes must explicitly "pair".
 
 What kind of tuning is done for Pentium 4? Why do you think it doesn't
 adversely affect performance on P6 and similar machines (Athlons and
 such)? I'm currently somewhat out-of-date, so i don't even know what
 kind of new optimizations Pentium 4 can apply or where new bottlenecks
 are.
 
 BTW, the naming "P4" is problematic. You see why above. Is there any
 other short for it, or should i just get used to calling older systems
 i586/i686 instead of P5/P6?
 
 -eye


Frankly and on second thought, I could be wrong to suggest this, because I'm
basing that suggestion off of tests done with an older-than-current version
of GCC and only on a PIII to compare it with.

What I've noticed in the benchmarks I've run is that -mcpu=pentium4 does
generally make some code a decent amount faster on both P4 and
AthlonXP/AMD64 (32 bit mode) chips, while not really effecting the results
on the PIII class chips.

OTOH though, if you 'tune' an executable or a compiler/runtime/whatever for
the higher-end chips, the people who use the lower-end chips scream bloody
murder.. I kind of look at it from the other angle - I think the people who
have invested (the money, time and effort) to upgrade shouldn't have to
default to the lowest common denominator, so maybe those people should be
the ones /really/ screaming bloody murder <g>

Anyhow, I thought maybe since D won't have all of the legacy code issues to
deal with, it may be a good time to 'tune' GDC for the higher-end chips.

- Dave

Oct 04 2004

↑ ↓ ← → Ilya Minkov <minkov cs.tum.edu> writes:

Dave schrieb:
 Frankly and on second thought, I could be wrong to suggest this, because I'm
 basing that suggestion off of tests done with an older-than-current version
 of GCC and only on a PIII to compare it with.


Not necessarily. However, all the options are alredy there, so i think 
it just may be up to application author to decide.

 What I've noticed in the benchmarks I've run is that -mcpu=pentium4 does
 generally make some code a decent amount faster on both P4 and
 AthlonXP/AMD64 (32 bit mode) chips, while not really effecting the results
 on the PIII class chips.


Interesting. I had considered Athlon-XP to be rather similar to P6 
(Pentium 3), and Pentium 4 somewhat different, but apparently i was 
wrong. Perhaps some optimizations caused some kind of performance "trap" 
on both recent AMDs and on Pentium 4, which weren't there in prior 
architectures. Gotta read something on it.

 OTOH though, if you 'tune' an executable or a compiler/runtime/whatever for
 the higher-end chips, the people who use the lower-end chips scream bloody
 murder.. I kind of look at it from the other angle - I think the people who
 have invested (the money, time and effort) to upgrade shouldn't have to
 default to the lowest common denominator, so maybe those people should be
 the ones /really/ screaming bloody murder <g>


It is only tuning... the command set in use is still as for 386, yes? I 
think it's a pity and Pentium (but perhaps nothing above) should be 
mandatory.

 Anyhow, I thought maybe since D won't have all of the legacy code issues to
 deal with, it may be a good time to 'tune' GDC for the higher-end chips.


Legacy *code* issues? There is no effect on code compatibility, the only 
consern is a compatible hardware. I would argue that D requieres an 
architecture with pretty much memory anyway, and computers old enough 
are more or less out of question already for that reason.

-eye

Oct 04 2004

↑ ↓ ← → Dave <Dave_member pathlink.com> writes:

Ilya Minkov wrote:

 Dave schrieb:


 
 It is only tuning... the command set in use is still as for 386, yes? I
 think it's a pity and Pentium (but perhaps nothing above) should be
 mandatory.
 


Yea - it is only tuning, but nonetheless I didn't put enough thought into
the original -mcpu=pentium4 suggestion. Especially given this response by
the maintainer of GDC:

D.gnu/791

 Anyhow, I thought maybe since D won't have all of the legacy code issues
 to deal with, it may be a good time to 'tune' GDC for the higher-end
 chips.


 Legacy *code* issues? There is no effect on code compatibility, the only
 consern is a compatible hardware. I would argue that D requieres an
 architecture with pretty much memory anyway, and computers old enough
 are more or less out of question already for that reason.
 
 -eye


By "legacy code issues", I should have said something more along the lines
of 'all that code running running on older hardware', which is what I
intended.

Thanks,

- Dave

Oct 04 2004