Dave wrote:
> [...]
> 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):

All the world is not using Pentiums (just as in a previous generation, all the world was not a VAX) -- some people use other CPU chips. Specifically, MacOS X uses PowerPC.  I assume that this would have been noted and covered - just double-checking.

-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Jonathan Leffler wrote:
> All the world is not using Pentiums (just as in a previous generation, all the world was not a VAX) -- some people use other CPU chips. Specifically, MacOS X uses PowerPC.  I assume that this would have been noted and covered - just double-checking.

And that I use amd64 is around the most important reason I am so interested in gdc :)

-ben

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

Benjamin Herr wrote:

[snip]
> 
> I am looking forward to this weekend for yet one more reason then :)
> I would appreciate if you provided your test suite so I could do some amd64 tests, once I manage to build gdc.
> 
> Also, if I can help you without challenging my less than awesome coding skills, I would like to assist.
> 
> -ben

Ben,

Adding 64-bit support to gdc is going to require a lot of changes to Phobos.  You can help by identifying what needs to be changed and/or coding.  I don't have access to a 64-bit environment (*) so this will be  a big help.

David

(*) Hoping Apple releases Tiger soon...

David Friedman wrote:
> Ben,
> 
> Adding 64-bit support to gdc is going to require a lot of changes to Phobos.  You can help by identifying what needs to be changed and/or coding.  I don't have access to a 64-bit environment (*) so this will be  a big help.
> 
> David
> 
> (*) Hoping Apple releases Tiger soon...

$ gdc 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

Release 1f did not fail like this, which surprises me.

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/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

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

>> 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

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/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

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

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