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