<div dir="ltr">On 12 August 2013 12:22, Shuxin Yang <span dir="ltr"><<a href="mailto:shuxin.llvm@gmail.com" target="_blank">shuxin.llvm@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 8/12/13 12:16 PM, Nick Lewycky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Shuxin Yang wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Author: shuxin_yang<br>
Date: Mon Aug 12 13:29:43 2013<br>
New Revision: 188188<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=188188&view=rev" target="_blank">http://llvm.org/viewvc/llvm-<u></u>project?rev=188188&view=rev</a><br>
Log:<br>
Misc enhancements to LTO:<br>
<br>
   1. Add some helper classes for partitions. They are designed in a<br>
      way such that the top-level LTO driver will not see much difference<br>
      with or without partitioning.<br>
<br>
   2. Introduce work-dir. Now all intermediate files generated during<br>
      LTO phases will be saved under work-dir. User can specify the workdir<br>
      via -lto-workdir=/path/to/dir. By default the work-dir will be<br>
      erased before linker exit. To keep the workdir, do -lto-keep, or -lto-keep=1.<br>
<br>
     TODO: Erase the workdir, if the linker exit prematurely.<br>
       We are currently not able to remove directory on signal. The support<br>
       routines simply ignore directory.<br>
<br>
   3. Add one new API lto_codegen_get_files_need_<u></u>remove().<br>
      Linker and LTO plugin will communicate via this API about which files<br>
     (including directories) need to removed before linker exit.<br>
</blockquote>
<br>
Please revert. Adding new flags to libLTO is the wrong direction (in spite of the ones that exist -- consider those grandfathered in). <br>
</blockquote></div>
It dose not make sense. Without flags, how do you manage to triage the correctness and performance problem?<br></blockquote><div><br></div><div>Something else has flags, which in turn drives libLTO through the API.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Adding flags to linker instead, I think that is wrong direction. Linker dose not have data structure which libLTO dose.</blockquote><div><br></div><div>This is the discussion to have. What things do you need here which you don't think should be exposed through the API, and yet you want to be exposed for you?</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">libLTO is intended to be used as a library, it may not get a chance to parse flags.<br>
</div>

It has to. Prior to my change, linkers (GNU linker and Apple ld) pass arch to linker, via a function<br>
confusingly called, something like "add.*debug.*options".</blockquote><div><br></div><div>Can't. If we allow this, every flag in every part of LLVM that libLTO links against is baked into the C ABI forever.</div>

<div><br></div><div>Of course addDebugOptions does allow this, but it's named (and I thought documented in the comments) such that anybody using it knows they're using a non-stable non-production debugging API. Anybody using addDebugOptions for something other than debugging libLTO is living outside the ABI guarantees.</div>

<div><br></div><div>Nick</div><div><br></div></div></div></div>