<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 8/12/13 1:03 PM, Nick Lewycky wrote:<br>
    </div>
    <blockquote
cite="mid:CADbEz-i6e7hxT_SFLZCJavsSQwB=QC-1Q=RF7aLHk_XD=t-v=w@mail.gmail.com"
      type="cite">
      <div dir="ltr">On 12 August 2013 12:22, Shuxin Yang <span
          dir="ltr"><<a moz-do-not-send="true"
            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 moz-do-not-send="true"
                      href="http://llvm.org/viewvc/llvm-project?rev=188188&view=rev"
                      target="_blank">http://llvm.org/viewvc/llvm-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_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, </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    What are "something else"?  As far as I know, there are only two
    fall into this category:<br>
    <br>
       - Apple linker, and<br>
       - GNU gold. <br>
    <br>
      The former communicate with the libLTO directly with these APIs,
    while GNU gold communicate <br>
    with the libLTO via, which I called adapter. <br>
    <br>
       Directly calling these APIs is really bad idea. I manage to
    convince the black-belt guru Nick @ Apple to <br>
    not directly calling these APIs in the new ld design. The linker's
    should be LTO oblivious, the linker <br>
    should expose symbol-related interface instead of LTO-control
    interfaces. <br>
    <br>
    >which in turn drives libLTO through the API.<br>
    <br>
    Depending on the what kind of info "something" else need to drive
    the libLTO. <br>
    In general it is very bad idea, if "something else" need
    micro-management. <br>
    <br>
    Take Apple ld as example,  if I want to change LTO in a way such
    that I don't want to load all module, <br>
    I just want to load summary info. Current APIs are not sufficient. I
    have to modify the API, or add new APIs<br>
    to that matter, in the mean time, I need release the new ld to the
    user in order to accomodate the change. <br>
    that is nightmare.  <br>
    <br>
    Sure, "something else" can control the libLTO, if it want. In my
    case, if "something else" want specify <br>
     a workdir, then go ahead. Otherwise, the libLTO use default one. Is
    there any wrong here?<br>
    <br>
    <br>
    <blockquote
cite="mid:CADbEz-i6e7hxT_SFLZCJavsSQwB=QC-1Q=RF7aLHk_XD=t-v=w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <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>
        </div>
      </div>
    </blockquote>
    I actually discuss with Nick @ Apple before.  The conclusion is
    linker must be LTO oblivious, <br>
    it should think in symbol-way, and talk in symbol way (as with GNU
    gold). It would otherwise<br>
     very very troublesome both for linker and libLTO. <br>
    <br>
    On the other hand, we now have two linkers support LTO. There are
    different way to control <br>
    the libLTO (even for simple task, like save intermediate files), how
    messy?<br>
    <br>
    I'd like to move all these stuff to libLTO to have a unified
    control. <br>
    <br>
    <br>
    <blockquote
cite="mid:CADbEz-i6e7hxT_SFLZCJavsSQwB=QC-1Q=RF7aLHk_XD=t-v=w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <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>
        </div>
      </div>
    </blockquote>
    addDebugOptions is misnomer. It is also passes essential flags like
    -arch=x86.  Without such flags, <br>
    the LTO dose not even compile. <br>
    <br>
    <br>
    <br>
  </body>
</html>