On 01/19/2016 08:45 AM, Jan Hubicka wrote:
Hi,
this patch mentiones few user visible changes I can think of.  I will
add some quality data on firefox once stage3 closes.

It seems that the optimization section of changes.html deserve some work :)

Honza

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.46
diff -u -r1.46 changes.html
--- changes.html        22 Dec 2015 19:23:31 -0000      1.46
+++ changes.html        19 Jan 2016 15:42:56 -0000
@@ -43,6 +43,64 @@
        of array bounds.  In particular, it enables
        <code>-fsanitize=bounds</code> as well as instrumentation of
        flexible array member-like arrays.</li>
+    <li>Type based alias analysis now disambiguate accesses to different

s/Type based/Type-based/
s/disambiguate/disambiguates/

+       pointers. This improve precision of the alias oracle by about 20-30%

s/improve/improves/

+       on higher-level C++ programs. Programs doing invalid type punning
+       of pointer types may now need <code>-fno-strict-aliasing</code>
+       to work correctly.</li>
+    <li>Alias oracle now correctly supports <code>weakref</code> and

Are users supposed to know what "Alias oracle" is?  (I don't....)

+       <code>alias</code> attributes. This makes it possible to access
+       both variable and its alias in one translation unit which is common

s/variable/a variable/

+       with link-time optimization.</li>
+    <li>Value range propagation now assume that <code>this</code> pointer

s/assume/assumes/

+       of C++ methods is non-NULL.  This eliminates many NULL pointer checks
+       but also breaks some non-conforming code-bases (such as Qt-5, Chromium,
+       KDevelop). As a termporary work-around
+       <code>-fno-delete-null-pointer-checks</code> can be used. Wrong
+       code can be identified <code>-fsanitize=undefined</code>.</li>

s/identified/identified by using/

+    <li>Link-time optimization improvements:
+    <ul>
+      <li><code>warning</code> and <code>error</code> attributes are now
+         correctly preserved by the declaration linking and thus

s/the declaration/declaration/

+         <code>-D_FORTIFY_SOURCE=2</code> is now supported with 
<code>-flto</code>.</li>
+      <li><p>Type merging was fixed to handle C and Fortran interoperability
+         rules as defined by the Fortran2005 language standard.</p>

"Fortran2005" seems unlikely to be the correct spelling, and Wikipedia doesn't think there was a 2005 version of the Fortran standard at all. I'm confused.

+         <p>
+         As an exception, <code>CHARACTER(KIND=C_CHAR)</code> is not 
inter-operable
+         with <code>char</code> in all cases because it is an array while
+         <code>char</code> is scalar.
+         <code>INTEGER(KIND=C_SIGNED_CHAR)</code> should be used instead.
+         In general, this inter-operability can not be implemented, for
+         example, on targets where function passing conventions of arrays
+         differs from scalars.</p>
+      <li>More of type information is now preserved at link-time reducing

s/More of/More/
s/link-time/link time,/

+         the loss of accuracy of the type based alias analysis oracle compared

s/type based/type-based/

Again, is "oracle" implementor-speak?

+         to builds without link time optimization.</li>

s/link time/link-time/

+      <li>Invalid type punning on global variables and declarations is now
+         reported with <code>-Wodr-type-mismatch</code>.</li>
+      <li>The size of LTO object files was reduced by about 11% (measured
+         by compiling Firefox 46.0).</li>
+      <li>Link-time parallelization (enabled using <code>-flto=n</code>)
+         was significantly improved by decreasing the size of streamed
+         data when partitioning program.  The size of streamed

s/program/programs/

+         IL while compiling Firefox 46.0 was reduced by 66%.</li>

"IL" == implementor-speak.... Do users care about this statistic, or only about increased parallelism?

+      <li>Linker plugin was extended to pass information about type of

s/Linker plugin/The linker plugin

+         binary produced to GCC back-end (that can be also manually controlled

s/GCC back-end/the GCC back end/

+         by <code>-flinker-output</code>).  This makes it possible to
+         properly confiugre code generator and support incremental

s/confiugre/configure/

+         linking. Inremental linking of LTO objects by <code>gcc -r</code> is

s/Iremental/Incremental/

+         now supported on plugin enabled setups. Because code generation 
happens

s/plugin enabled/plugin-enabled/

+         during the incremnetal linking step, the whole program optimization

s/incremnetal/incremental/

+         is not performed. GCC 7 will support incremental IL linking.</li>

"IL" again....  what does this mean to users?

+    </ul></li>
+    <li>Inter-procedural optimization improvements:
+    <ul>
+      <li>Basic jump threading is now performed before profile construction
+         and inline analysis resulting in more realistic size and time 
estimates

s/analysis/analysis,/

+         that drive heuristics of inliner and function cloning passes.</li>

s/heuristics of/the heuristics of the/

+      <li>Function cloning now more aggressively eliminate unused function

s/eliminate/eliminates/

+         parameters.</li>
+    </ul></li>
    </ul>

  <!-- .................................................................. -->


-Sandra the nit-picky

Reply via email to