[wwwdocs] Changes for LTO and IPA, ver 2

[Jan Hubicka]

Hi,
it seems I have updated the patch for comments received but did not send
updated version to the ML. Here it is.

Honza

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.58
diff -c -3 -p -r1.58 changes.html
*** changes.html	15 Feb 2016 11:32:56 -0000	1.58
--- changes.html	18 Feb 2016 04:16:50 -0000
*************** For more information, see the
*** 50,55 ****
--- 50,124 ----
  	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 disambiguates accesses to different
+ 	pointers. This improves precision of the alias oracle by about 20-30%
+ 	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 analysis now correctly supports <code>weakref</code> and
+ 	<code>alias</code> attributes. This makes it possible to access
+ 	both a variable and its alias in one translation unit which is common
+ 	with link-time optimization.</li>
+     <li>Value range propagation now assumes that <code>this</code> pointer
+ 	of C++ member functions is non-<code>NULL</code>.  This eliminates 
+ 	common <code>NULL</code> pointer checks
+ 	but also breaks some non-conforming code-bases (such as Qt-5, Chromium,
+ 	KDevelop). As a temporary work-around
+ 	<code>-fno-delete-null-pointer-checks</code> can be used. Wrong
+ 	code can be identified by using <code>-fsanitize=undefined</code>.</li>
+     <li>Link-time optimization improvements:
+     <ul>
+       <li><code>warning</code> and <code>error</code> attributes are now
+ 	  correctly preserved by declaration linking and thus
+ 	  <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 Fortran 2008 language standard.</p>
+ 	  <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 type information is now preserved at link time reducing
+ 	  the loss of accuracy of the type based alias analysis compared
+ 	  to builds without link-time optimization.</li>
+       <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 programs.  The size of streamed
+ 	  IL while compiling Firefox 46.0 was reduced by 66%.</li>
+       <li><p>Linker plugin was extended to pass information about type of
+ 	  binary produced to GCC back-end (that can be also manually controlled
+ 	  by <code>-flinker-output</code>).  This makes it possible to
+ 	  properly confiugre code generator and support incremental
+ 	  linking. Incremental linking of LTO objects by <code>gcc -r</code> is
+ 	  now supported on plugin-enabled setups.</p>
+ 	  <p>There are two ways to perform incremental linking:
+ 	  <ol>
+ 	     <li>Linking by <code>ld -r</code> will result in object file
+ 	     with all sections from individual object files mechanically merged.
+ 	     This delays the actual linking to the time final binary is produced
+ 	     and thus permits whole program optimization.  Linking such object
+ 	     file is however slower.
+ 	     <li>Linking by <code>gcc -r</code> will lead to link time optimization
+ 	     and produce final binary into the object file.  Linking such object
+ 	     file is fast but avoids any benefirts from whole program optimization.</li>
+ 	  </ol>
+ 	  GCC 7 will support incremental link-time optimization with <code>gcc -r</code>.
+     </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
+ 	  that drive the heuristics of the of inliner and function cloning passes.</li>
+       <li>Function cloning now more aggressively eliminates unused function
+ 	  parameters.</li>
+     </ul></li>
    </ul>
  
  <!-- .................................................................. -->