material for 3.1 release announcement

material for 3.1 release announcement

[Joe Buck]

It seems that no one has collected a list of features to brag about for
the 3.1 release.  Some highlights off the top of my head:

* New x86 backend, with much better codegen for newer Intel processors
  including the P4, which was handled poorly by earlier gcc's.

* Sparc version: one compiler generates both 32-bit and 64-bit code (-m64)

* New AMD Hammer (x86-64) backend.

* Integrated GNU Ada frontend.

* Much-improved C++ standard library with great Doxygen-generated
  hypertext documentation.

* Many bug fixes.

Please send suggestions for others, or any comments on the above list.

Re: material for 3.1 release announcement

[Gerald Pfeifer]

On Thu, 2 May 2002, Joe Buck wrote:

> It seems that no one has collected a list of features to brag about for
> the 3.1 release.  Some highlights off the top of my head:
>
> * New x86 backend, with much better codegen for newer Intel processors
>   including the P4, which was handled poorly by earlier gcc's.
>
> * Sparc version: one compiler generates both 32-bit and 64-bit code (-m64)
>
> * New AMD Hammer (x86-64) backend.
>
> * Integrated GNU Ada frontend.
>
> * Much-improved C++ standard library with great Doxygen-generated
>   hypertext documentation.
>
> * Many bug fixes.
>
> Please send suggestions for others, or any comments on the above list.

...and go ahead an commit patches describing any such new features
to gcc-3.1/changes.html.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: material for 3.1 release announcement

[Joe Buck]

I wrote:
> > It seems that no one has collected a list of features to brag about for
> > the 3.1 release.  Some highlights off the top of my head:
> > ...
> > * Much-improved C++ standard library with great Doxygen-generated
> >   hypertext documentation.

Gerald writes:
> ...and go ahead an commit patches describing any such new features
> to gcc-3.1/changes.html.

The release announcements would only include a subset of that page,
perhaps with a pointer to it.

I'm not sure that the way that page is written, it is clear enough to
the casual reader that one compiler produces both 32 and 64 bit code
on the UltraSPARC, especially since with 3.0, one could produce a
64-bit-only compiler by going through a great deal of pain.  Something like

For UltraSPARC, GCC can produce either 32-bit code (by default) 
or 64-bit code (if the option -m64 is provided).

might be better

The only thing missing from my list in changes.html is the libstdc++
modifications; someone from the libstdc++ team should decide what to
write there.

Re: material for 3.1 release announcement

[Jan Hubicka]

> On Thu, 2 May 2002, Joe Buck wrote:
> 
> > It seems that no one has collected a list of features to brag about for
> > the 3.1 release.  Some highlights off the top of my head:
> >
> > * New x86 backend, with much better codegen for newer Intel processors
> >   including the P4, which was handled poorly by earlier gcc's.
> >
> > * Sparc version: one compiler generates both 32-bit and 64-bit code (-m64)
> >
> > * New AMD Hammer (x86-64) backend.
> >
> > * Integrated GNU Ada frontend.
> >
> > * Much-improved C++ standard library with great Doxygen-generated
> >   hypertext documentation.
> >
> > * Many bug fixes.
> >
> > Please send suggestions for others, or any comments on the above list.
> 
> ...and go ahead an commit patches describing any such new features
> to gcc-3.1/changes.html.
This reminds me, that I would like to have the profile stuff mentioned in
hope that people will actually start to use it.

*** changes.html.1	Thu May  2 17:19:05 2002
--- changes.html	Thu May  2 19:06:59 2002
*************** GCC 3.1 Changes, New Features, and Fixes
*** 59,65 ****
  <h2>General Optimizer Improvements</h2>
  
  <ul>
!   <li>dummy</li>
  </ul>
  
    
--- 59,73 ----
  <h2>General Optimizer Improvements</h2>
  
  <ul>
!   <li>Jan Hubicka, SuSE Labs, together with Richard Henderson, Red Hat, and
!       Andreas Jaeger, SuSE Labs, has contributed <a
!       href="news/profiledriven.html">infrastructure for profile driven
!       optimizations</a>
!       <p>
!       Options -fprofile-arcs and -fbranch-probabilities can now be used to
!       improve speed of the generated code by profiling the actual program
!       behaviour on typical run.  In the absence of profile info compiler
!       attempts to guess the profile statically.</p>
  </ul>
  
    

Re: material for 3.1 release announcement

[Gerald Pfeifer]

On Thu, 2 May 2002, Jan Hubicka wrote:
>   <ul>
> !   <li>Jan Hubicka, SuSE Labs, together with Richard Henderson, Red Hat, and
> !       Andreas Jaeger, SuSE Labs, has contributed <a
> !       href="news/profiledriven.html">infrastructure for profile driven
> !       optimizations</a>

"." at the end of the sentence, and paragraphs need to start with <p>
and end with </p>.

> !       <p>
> !       Options -fprofile-arcs and -fbranch-probabilities can now be used to
> !       improve speed of the generated code by profiling the actual program
> !       behaviour on typical run.  In the absence of profile info compiler
> !       attempts to guess the profile statically.</p>
>   </ul>

<code>-fprofile-arcs</code> and <code>-fbranch-probabilities</code>

"on typical runs" or "on a typical run".

"the compiler".

Fine with these changes. Thanks!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: material for 3.1 release announcement

[Jan Hubicka]

> On Thu, 2 May 2002, Jan Hubicka wrote:
> >   <ul>
> > !   <li>Jan Hubicka, SuSE Labs, together with Richard Henderson, Red Hat, and
> > !       Andreas Jaeger, SuSE Labs, has contributed <a
> > !       href="news/profiledriven.html">infrastructure for profile driven
> > !       optimizations</a>
> 
> "." at the end of the sentence, and paragraphs need to start with <p>
> and end with </p>.
> 
> > !       <p>
> > !       Options -fprofile-arcs and -fbranch-probabilities can now be used to
> > !       improve speed of the generated code by profiling the actual program
> > !       behaviour on typical run.  In the absence of profile info compiler
> > !       attempts to guess the profile statically.</p>
> >   </ul>
> 
> <code>-fprofile-arcs</code> and <code>-fbranch-probabilities</code>
> 
> "on typical runs" or "on a typical run".
> 
> "the compiler".
> 
> Fine with these changes. Thanks!

Thanks, I've commited it.  Other optimizations that come into mind
and should not be forgotten are:
Hard register copy propagation by Richard Henderson, alias analysis/alignment
stuff by Richard Kenner, tree based inlining on C by Alexandre (is that already
in 3.0?), but I don't feel authorized to write about.

What may or may not be noticed IMO is the jump optimization rewrite (it does
not really brings easy to describe value to the user), perhaps
optimize_mode_swithching for i387 control word, GCSE improvements by Richard
Kenner.  It is interesting how few new optimizations come to mind offhand, I
will think about it later.

Perhaps we can just mention that the spec2000 results are better by about 6% on
-O2 level of optimizations (8.2% with PDO) compared to gcc 3.0, while gcc 3.0
improved by 2.1% compared to gcc 2.95 according to the Andreas tester.

Honza
> 
> Gerald
> -- 
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: material for 3.1 release announcement

[Gerald Pfeifer]

On Thu, 2 May 2002, Jan Hubicka wrote:
> Hard register copy propagation by Richard Henderson, alias
> analysis/alignment stuff by Richard Kenner, tree based inlining on C by
> Alexandre (is that already in 3.0?), but I don't feel authorized to
> write about.

Ideally those having contributed the improvements would write something.

> Perhaps we can just mention that the spec2000 results are better by
> about 6% on -O2 level of optimizations (8.2% with PDO) compared to gcc
> 3.0, while gcc 3.0 improved by 2.1% compared to gcc 2.95 according to
> the Andreas tester.

Yes, please add this (probably under "General Optimizer Improvements").

Gerald

PS: I'll have very intermittent Internet access for the next few days.
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: material for 3.1 release announcement

[Jan Hubicka]

> 
> Ideally those having contributed the improvements would write something.

Hope so :)

> 
> > Perhaps we can just mention that the spec2000 results are better by
> > about 6% on -O2 level of optimizations (8.2% with PDO) compared to gcc
> > 3.0, while gcc 3.0 improved by 2.1% compared to gcc 2.95 according to
> > the Andreas tester.
> 
> Yes, please add this (probably under "General Optimizer Improvements").

Here is an attempt to do so.

Index: gcc-3.1/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/changes.html,v
retrieving revision 1.27
diff -c -3 -p -r1.27 changes.html
*** gcc-3.1/changes.html	3 May 2002 12:25:35 -0000	1.27
--- gcc-3.1/changes.html	3 May 2002 13:20:24 -0000
***************
*** 37,42 ****
--- 37,53 ----
        the generated code by profiling the actual program behaviour on typical
        runs.  In the absence of profile info the compiler attempts to guess the
        profile statically.</p>
+ 
+       <li><p><a HREF="http://www.suse.de/~aj/SPEC">SPEC2000</a> and <a
+       HREF="http://people.redhat.com/dnovillo/SPEC">SPEC95</a> benchmark suites
+       are now used daily to monitor performance of the generated code to avoid
+       performance regressions to leak into compiler and stay unnoticed.</p>
+ 
+       <p>According to the SPECInt2000 results on AMD Athlon CPU, the code
+       generated by GCC 3.1.0 is at the average 6% faster (8.2% faster with
+       profile feedback) compared to GCC 3.0.0.  The code produced by GCC 3.0.0
+       is about 2.1% faster compared to 2.95.3.  Tests were done with <code>-O2
+       -march=athlon</code> command line options.</p>
  </ul>
  
    

Re: material for 3.1 release announcement

[Gerald Pfeifer]

On Fri, 3 May 2002, Jan Hubicka wrote:
> Here is an attempt to do so.

Thanks!

> +       <li><p><a HREF="http://www.suse.de/~aj/SPEC">SPEC2000</a> and <a
> +       HREF="http://people.redhat.com/dnovillo/SPEC">SPEC95</a> benchmark suites
> +       are now used daily to monitor performance of the generated code
"href" instead of "HREF", and I believe that both URLs lack a trailing
"/".

> +       to avoid
> +       performance regressions to leak into compiler and stay unnoticed.</p>

I'd omit this part, because "monitoring" already implies this, and we are
also interested to spot improvements, aren't we? ;-)

> +       <p>According to the SPECInt2000 results on AMD Athlon CPU, the code
> +       generated by GCC 3.1.0 is at the average 6% faster (8.2% faster with
> +       profile feedback) compared to GCC 3.0.0.

"on an AMD Athlon", "is 6% faster on average", "with profile driven
feedback".

For historical reasons the first releases are called 3.1 and 3.0,
respectively.

> +       Tests were done with <code>-O2
> +       -march=athlon</code> command line options.</p>

"using the <code>...</code> command-line options.</p>"

And I believe there is an </li> missing at the end.

The patch is fine with the changes above. To make sure, please run the
validator (by clicking the button in the lower right corner of the web
page) after the commit.

Thanks!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: material for 3.1 release announcement

[Jan Hubicka]

> On Fri, 3 May 2002, Jan Hubicka wrote:
> > Here is an attempt to do so.
> 
> Thanks!
> 
> > +       <li><p><a HREF="http://www.suse.de/~aj/SPEC">SPEC2000</a> and <a
> > +       HREF="http://people.redhat.com/dnovillo/SPEC">SPEC95</a> benchmark suites
> > +       are now used daily to monitor performance of the generated code
> "href" instead of "HREF", and I believe that both URLs lack a trailing
> "/".
Somehow I did changes you requested but missed this one.  It probably scrolled
out of screen, sorry.

While looking at it, I noticed that we document prefetching for i386, but don't
document -fprefetch-loop-arrays and new builtin.  Also I added bit
clarification to SSE support and notice about fp->int converison (we are about
10 times faster there as 3.0.x had bug doing partial memory stall in the
middle, this is important showstopper for 3D people)

Here is another bunch of changes, let me know what of them seems
resonable.

Another idea is that we probably can mention the fact that code size has
dropped considerably (at both -O2 and -Os), but I don't have 3.0 here to get
some numbers. I guess this can be appealing to people building distros.

Honza

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/changes.html,v
retrieving revision 1.28
diff -c -3 -p -r1.28 changes.html
*** changes.html	3 May 2002 13:39:33 -0000	1.28
--- changes.html	3 May 2002 23:00:43 -0000
***************
*** 38,45 ****
        runs.  In the absence of profile info the compiler attempts to guess the
        profile statically.</p>
  </li>
! <li><p><a HREF="http://www.suse.de/~aj/SPEC">SPEC2000</a> and <a
!       HREF="http://people.redhat.com/dnovillo/SPEC">SPEC95</a> benchmark suites
        are now used daily to monitor performance of the generated code.
  
        <p>According to the SPECInt2000 results on an AMD Athlon CPU, the code
--- 38,45 ----
        runs.  In the absence of profile info the compiler attempts to guess the
        profile statically.</p>
  </li>
! <li><p><a href="http://www.suse.de/~aj/SPEC/">SPEC2000</a> and <a
!       href="http://people.redhat.com/dnovillo/SPEC/">SPEC95</a> benchmark suites
        are now used daily to monitor performance of the generated code.
  
        <p>According to the SPECInt2000 results on an AMD Athlon CPU, the code
***************
*** 48,53 ****
--- 48,61 ----
        about 2.1% faster compared to 2.95.3.  Tests were done using the
        <code>-O2 -march=athlon</code> command-line options.</p>
  </li>
+ 
+ <li<p>Support for data prefetching instructions has been added to the GCC
+       backend and several targets.  New <code>__builtin_prefetch</code>
+       instrics is available to explicitly insert prefetch instructions and
+       experimental support for loop array prefetching has been added (see
+       <code>-fprefetch-loop-array</code> documentation).
+ 
+ </li>
  </ul>
  
    
*************** documentation</a>.</p>
*** 189,195 ****
        
        <li>The compiler now supports MMX, 3DNow!, SSE, and SSE2 instructions.
        Options <code>-mmmx</code>, <code>-m3dnow</code>, <code>-msse</code>,
!       and <code>-msse2</code> will enable the respective instruction sets.</li>
  
        <li>Following those improvements, targets for Pentium MMX, K6-2, K6-3,
        Pentium III, Pentium 4, and Athlon 4 Mobile/XP/MP were added.
--- 197,205 ----
        
        <li>The compiler now supports MMX, 3DNow!, SSE, and SSE2 instructions.
        Options <code>-mmmx</code>, <code>-m3dnow</code>, <code>-msse</code>,
!       and <code>-msse2</code> will enable the respective instruction sets.
!       Intel C++ compatible MMX/3DNow!/SSE intrics are implemented.  SSE2
!       intrics will be added in next major release.</li>
  
        <li>Following those improvements, targets for Pentium MMX, K6-2, K6-3,
        Pentium III, Pentium 4, and Athlon 4 Mobile/XP/MP were added.
*************** documentation</a>.</p>
*** 199,208 ****
        <li>For those targets that support it, <code>-mfpmath=sse</code> will
        cause the compiler to generate SSE/SSE2 instructions for floating point
        math instead of x87 instructions.  Usually, this will lead to quicker
!       code &mdash; especially on the Pentium 4.</li>
  
        <li>Prefetch support has been added to the Pentium III, Pentium 4, and
        Athlon series.</li>
     </ul></li>
  
  <li>The PowerPC back-end has added 64-bit PowerPC GNU/Linux support.</li>
--- 209,222 ----
        <li>For those targets that support it, <code>-mfpmath=sse</code> will
        cause the compiler to generate SSE/SSE2 instructions for floating point
        math instead of x87 instructions.  Usually, this will lead to quicker
!       code &mdash; especially on the Pentium 4. Note that only sclar floating
!       point instructions are used and GCC does not exploit SIMD features yet.</li>
  
        <li>Prefetch support has been added to the Pentium III, Pentium 4, and
        Athlon series.</li>
+ 
+       <li>Code generated for floating point to integer converisons has been
+       improved leading to better performance of many 3D applications.</li>
     </ul></li>
  
  <li>The PowerPC back-end has added 64-bit PowerPC GNU/Linux support.</li>

Re: material for 3.1 release announcement

[Gerald Pfeifer]

On Sat, 4 May 2002, Jan Hubicka wrote:
> ! <li><p><a href="http://www.suse.de/~aj/SPEC/">SPEC2000</a> and <a
> !       href="http://people.redhat.com/dnovillo/SPEC/">SPEC95</a> benchmark suites
>         are now used daily to monitor performance of the generated code.

There seems </p> missing here.

> + <li<p>Support for data prefetching instructions has been added to the GCC
    ^^^^^^

<li> is sufficient.

> +       backend and several targets.  New <code>__builtin_prefetch</code>

"back end". "A new..."

> !       code &mdash; especially on the Pentium 4. Note that only sclar floating
> !       point instructions are used and GCC does not exploit SIMD features yet.</li>

"scalar"

Fine with these changes.  Please run the verifier (link in the lower right
corner) after committing to make sure we didn't miss anything.

Thanks,
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: material for 3.1 release announcement

[Jan Hubicka]

> On Sat, 4 May 2002, Jan Hubicka wrote:
> > ! <li><p><a href="http://www.suse.de/~aj/SPEC/">SPEC2000</a> and <a
> > !       href="http://people.redhat.com/dnovillo/SPEC/">SPEC95</a> benchmark suites
> >         are now used daily to monitor performance of the generated code.
> 
> There seems </p> missing here.
> 
> > + <li<p>Support for data prefetching instructions has been added to the GCC
>     ^^^^^^
> 
> <li> is sufficient.
> 
> > +       backend and several targets.  New <code>__builtin_prefetch</code>
> 
> "back end". "A new..."
> 
> > !       code &mdash; especially on the Pentium 4. Note that only sclar floating
> > !       point instructions are used and GCC does not exploit SIMD features yet.</li>
> 
> "scalar"
> 
> Fine with these changes.  Please run the verifier (link in the lower right
> corner) after committing to make sure we didn't miss anything.

Egads, I really should not be making documentation patches at midnight.
Thanks!

Honza
> 
> Thanks,
> Gerald
> -- 
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: material for 3.1 release announcement

[Alexandre Oliva]

On May  2, 2002, Jan Hubicka <jh@suse.cz> wrote:

> tree based inlining on C by Alexandre (is that already in 3.0?)

Thanks for the reminder.  Ok to install?

Index: gcc-3.1/changes.html
*** changes.html.~1.30.~	Fri May  3 17:29:09 2002
--- changes.html	Sat May  4 01:47:22 2002
***************
*** 40,46 ****
  </li>
  <li><p><a HREF="http://www.suse.de/~aj/SPEC">SPEC2000</a> and <a
        HREF="http://people.redhat.com/dnovillo/SPEC">SPEC95</a> benchmark suites
!       are now used daily to monitor performance of the generated code.
  
        <p>According to the SPECInt2000 results on an AMD Athlon CPU, the code
        generated by GCC 3.1 is 6% faster on the average (8.2% faster with
--- 40,46 ----
  </li>
  <li><p><a HREF="http://www.suse.de/~aj/SPEC">SPEC2000</a> and <a
        HREF="http://people.redhat.com/dnovillo/SPEC">SPEC95</a> benchmark suites
!       are now used daily to monitor performance of the generated code.</p>
  
        <p>According to the SPECInt2000 results on an AMD Athlon CPU, the code
        generated by GCC 3.1 is 6% faster on the average (8.2% faster with
***************
*** 48,53 ****
--- 48,61 ----
        about 2.1% faster compared to 2.95.3.  Tests were done using the
        <code>-O2 -march=athlon</code> command-line options.</p>
  </li>
+ 
+ <li><p>Alexandre Oliva, of <a href="http://www.redhat.com/">Red
+       Hat</a>, has generalized the tree inlining infrastructure
+       developed by <a
+       href="http://www.codesourcery.com/">CodeSourcery, LLC</a> for
+       the C++ front end, so that it is now used in the C front end
+       too.  Inlining functions as trees exposes them earlier to the
+       compiler, giving it more opportunities for optimization.</p>
  </ul>
  
    
***************
*** 188,193 ****
--- 196,206 ----
      system-on-a-chip series.  See <a
      href="http://developer.axis.com/">Axis' developer site</a> for
      technical information.</li>
+ 
+ <li>Alexandre Oliva, of <a href="http://www.redhat.com/">Red Hat</a>,
+     has contributed a port to the <a
+     href="http://www.superh.com/">SuperH</a> SH5 64-bit RISC
+     microprocessor architecture, extending the existing SH port.</li>
      
  <li>UltraSPARC is fully supported in 64-bit mode.  The option 
      <code>-m64</code> enables it.</li>


-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: material for 3.1 release announcement

[Gerald Pfeifer]

On 4 May 2002, Alexandre Oliva wrote:
> Thanks for the reminder.  Ok to install?

Yes, this looks fine, thanks.  (Do we want a comma before "too"?)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: material for 3.1 release announcement

[Richard Henderson]

On Thu, May 02, 2002 at 09:45:29AM -0700, Joe Buck wrote:
> * New x86 backend, with much better codegen for newer Intel processors
>   including the P4, which was handled poorly by earlier gcc's.

No, this was 3.0.


r~

Re: material for 3.1 release announcement

[Toon Moene]

Joe Buck wrote:
> 
> It seems that no one has collected a list of features to brag about for
> the 3.1 release.  Some highlights off the top of my head:

[ Snip ]

Optimizations:

Lots of backends support prefetching of array elements
in loops.

Underflow-forced-to-zero enabled at -ffast-math for lots of targets.

Fortran:

libf2c a shared library, which enables shared library components based
on Fortran code.

libf2c supports reading/writing of > 2Gbyte files on 32-bit targets.

frontend allows arrays up to 2 Gbyte in size (2**29 REALS, 2**28 DOUBLE
PRECISION or 2**27 COMPLEX*16 values).

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: material for 3.1 release announcement

[Aldy Hernandez]

>>>>> "Joe" == Joe Buck <Joe.Buck@synopsys.com> writes:

 > It seems that no one has collected a list of features to brag about for
 > the 3.1 release.  Some highlights off the top of my head:

experimental support for altivec.

I think a few people are actively using it, but i'd prefer to call it
experimental until i can pass the entire motorola altivec testsuite
;-)

Aldy

Re: material for 3.1 release announcement

[Benjamin Kosnik]

> The only thing missing from my list in changes.html is the libstdc++
> modifications; someone from the libstdc++ team should decide what to
> write there.

Yep. Phil and I discussed this yesterday: I'll come up with a list
today.

thanks,
benjamin