Re: [LTO merge][1/15][RFA] C front end

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 28 Sep 2009, Diego Novillo wrote:

> 2009-09-28  Diego Novillo  <dnovillo@google.com>
> 
> 	* c.opt: Add LTO to warn_abi and warn_psabi.
> 
> 2009-09-28  Ollie Wild  <aaw@google.com>
> 
> 	* c-opts.c (c_common_post_options): Handle -flto and -fwhopr.
> 
> diff -rdupN --exclude=.svn --exclude=.git --exclude='*.diff*' --exclude='autom4te*' --exclude=tags --exclude=ChangeLog.lto --exclude=configure /usr/local/google/homedirs/dnovillo/gcc/trunk/gcc/c.opt /usr/local/google/homedirs/dnovillo/gcc/trunk.lto/gcc/c.opt
> --- /usr/local/google/homedirs/dnovillo/gcc/trunk/gcc/c.opt	2009-09-23 12:45:47.000000000 -0400
> +++ /usr/local/google/homedirs/dnovillo/gcc/trunk.lto/gcc/c.opt	2009-09-23 11:15:13.000000000 -0400
> @@ -113,11 +113,11 @@ C ObjC C++ ObjC++ Joined Separate
>  -U<macro>	Undefine <macro>
>  
>  Wabi
> -C ObjC C++ ObjC++ Var(warn_abi) Warning
> +C ObjC C++ ObjC++ LTO Var(warn_abi) Warning
>  Warn about things that will change when compiling with an ABI-compliant compiler
>  
>  Wpsabi
> -C ObjC C++ ObjC++ Var(warn_psabi) Init(1) Undocumented
> +C ObjC C++ ObjC++ LTO Var(warn_psabi) Init(1) Undocumented

Wpsabi should be a language-independent option in common.opt.  If 
languages (as with Ada) do not care about it, they can turn it off.

As for Wabi, as far as I can see LTO only wants it in order to enable 
Wpsabi.  So the first question is: do -Wpsabi diagnostics have effect 
during initial compilation with each language's front end, during LTO 
optimization, or both?

If compiling an object with -flto passes the code through normal 
compilation stages to produce normal object code, in addition to producing 
encoded GIMPLE, that's going to produce the warnings, in which case 
warnings at the optimization stage aren't needed.  Does it?  I'll comment 
more on this when I review patch 5: the documentation is lacking any 
overall description of how LTO is used and what cases do or do not work, 
and such documentation is needed in addition to the descriptions of 
individual options, so I can't tell from the documentation whether or not 
normal object code will be generated.

The -Wpsabi diagnostics are ARM mangling diagnostics, which will be 
produced only at front-end stage (all mangling having happened before 
LTO), and IA32 argument-passing diagnostics.  So if the latter will be 
produced at front-end stage and LTO does not need to duplicate them, then 
LTO does not need to handle the -Wabi option.  On the other hand, if psABI 
handling will happen only at link time then LTO does need to handle -Wabi 
in order to set warn_psabi.  In either case, it seems reasonable to treat 
-Wabi as a language-independent option, with appropriate adjustments to 
its documentation.  But if psABI diagnostics have happened at front-end 
stage then LTO should disable warn_psabi to avoid them being duplicated; 
if not, LTO should arrange for them to be given according to the -Wpasbi 
setting *for the relevant object file* (remember, they won't be wanted for 
functions only defined in and called by Ada, which disables warn_psabi), 
and there should be a PR filed in Bugzilla if it doesn't presently handle 
them on a per-object-file basis.

> diff -rdupN --exclude=.svn --exclude=.git --exclude='*.diff*' --exclude='autom4te*' --exclude=tags --exclude=ChangeLog.lto --exclude=configure /usr/local/google/homedirs/dnovillo/gcc/trunk/gcc/c-opts.c /usr/local/google/homedirs/dnovillo/gcc/trunk.lto/gcc/c-opts.c
> --- /usr/local/google/homedirs/dnovillo/gcc/trunk/gcc/c-opts.c	2009-09-23 12:45:47.000000000 -0400
> +++ /usr/local/google/homedirs/dnovillo/gcc/trunk.lto/gcc/c-opts.c	2009-09-23 11:15:22.000000000 -0400
> @@ -1035,6 +1035,29 @@ c_common_post_options (const char **pfil
>    C_COMMON_OVERRIDE_OPTIONS;
>  #endif
>  
> +  if (flag_lto || flag_whopr)
> +    {
> +#ifdef ENABLE_LTO
> +      flag_generate_lto = 1;
> +
> +      /* When generating IL, do not operate in whole-program mode.
> +	 Otherwise, symbols will be privatized too early, causing link
> +	 errors later.  */
> +      flag_whole_program = 0;
> +
> +      /* FIXME lto.  Disable var-tracking until debug information
> +	 is properly handled in free_lang_data.  */
> +      flag_var_tracking = 0;
> +#else
> +      error ("LTO support has not been enabled in this configuration");
> +#endif
> +    }
> +
> +  /* Reconcile -flto and -fwhopr.  Set additional flags as appropriate and
> +     check option consistency.  */
> +  if (flag_lto && flag_whopr)
> +    error ("-flto and -fwhopr are mutually exclusive");
> +

All this should be common code not duplicated in multiple front ends.  If 
there's an issue with the LTO front end needing a different version, 
define a common function with this code called by every non-LTO front end.

-- 
Joseph S. Myers
joseph@codesourcery.com