<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 23, 2014 at 3:24 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> From: "Nick Lewycky" <<a href="mailto:nlewycky@google.com">nlewycky@google.com</a>><br>
> To: "llvm cfe" <<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a>><br>
> Sent: Thursday, October 23, 2014 4:39:59 PM<br>
> Subject: patch: add a driver flag to turn on function merging optimization<br>
><br>
> The attached patch adds -fmerge-functions which is in turn attached<br>
> to PassManagerBuilder::MergeFunctions. This is provided for testing<br>
> it out, and we can decide what we want the default to be after we<br>
> have experience. Note that it does bad things to debug info which<br>
> doesn't currently have a way to represent which function got called<br>
> if two functions were merged.<br>
<br>
</div></div>So we seem to be somewhat inconsistent about this, but I thought that the general pattern was that we resolve the multiple -ffoo vs. -fno-foo in the driver, and just pass one relevant flag to -cc1. For example, the code for -freroll-loops, -no-integrated-as, etc. does this:<br>
<br>
  Args.AddLastArg(CmdArgs, options::OPT_fwritable_strings);<br>
  Args.AddLastArg(CmdArgs, options::OPT_funroll_loops,<br>
                  options::OPT_fno_unroll_loops);<br>
<br>
  Args.AddLastArg(CmdArgs, options::OPT_pthread);<br>
<br>
and then the -cc1 code just does this:<br>
<br>
  if (Args.hasArg(OPT_pthread))<br>
    Opts.POSIXThreads = 1;<br>
<br>
  Opts.RerollLoops = Args.hasArg(OPT_freroll_loops);<br>
<br>
  Opts.DisableIntegratedAS = Args.hasArg(OPT_fno_integrated_as);<br>
<br>
It is unclear to me what the best practice is here, but perhaps it is worth a quick clarification.<br></blockquote><div><br></div><div>Yes, that's the usual pattern; we try to keep the frontend dumb and put all the complex resolution of conflicting / overriding flags into the driver. That means we try to only have flags that change the frontend away from its default behavior.</div></div></div></div>