<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 09/08/2014 01:26 PM, Joerg
      Sonnenberger wrote:<br>
    </div>
    <blockquote cite="mid:20140908182605.GA15711@britannica.bec.de"
      type="cite">
      <pre wrap="">On Mon, Sep 08, 2014 at 10:59:17AM -0700, Bob Wilson wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">
</pre>
        <blockquote type="cite">
          <pre wrap="">On Sep 8, 2014, at 10:14 AM, Joerg Sonnenberger <a class="moz-txt-link-rfc2396E" href="mailto:joerg@britannica.bec.de"><joerg@britannica.bec.de></a> wrote:

On Fri, Sep 05, 2014 at 09:23:34PM -0500, Richard Pennington wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Right now it only handles replacing a "-target foo" option
with the options defined in the file foo in the resource/config
directory, but I think it has potential for doing quite a bit more.
</pre>
          </blockquote>
          <pre wrap="">
Please don't overload the -target option like that, but make it a
separate option.
</pre>
        </blockquote>
        <pre wrap="">
I disagree. One of the problems with clang’s driver now is that we have
such a long list of built-in targets. From the user’s point of view,
whether the target settings come from a yaml file or from hardcoded
logic in the driver should be an implementation detail. It would be
great if we could default to specify _all_ targets like this, and then
choose which targets to build into the driver based solely on
performance.
</pre>
      </blockquote>
      <pre wrap="">
Whether it is reasonably possible for such a transistion has to be seen.
If you look at the target logic in the driver, you will seen that
estimated 70% of the complexity is related to Linux, maybe 10% each to
Darwinish systems and Windows and the rest for all other targets
together. So while this can greatly simplify the maintainance cost and
overall code size for Linux, it createse a complexity regression for
other systems. That's a good enough reason for my request to keep it
optional. I'm not against this feature -- if it is well done, it can
improve the status quo. But I am against forced overhead for systems
where we don't need it.
</pre>
    </blockquote>
    I agree that all drivers should not have to pay the overhead of
    reading a file for each compilation. I've updated my blog post with
    a bit more information (
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <a href="http://ellcc.org/blog/?p=11877">http://ellcc.org/blog/?p=11877</a>).
    Here's the gist of it:<br>
    <br>
    I use the -target argument, or the prefix on the compiler name, to
    try to open the config file. If a file of that name isn't found, the
    -target argument passes through unscathed and works as it does now.
    I use YAMLIO to read the configuration into a structure...<br>
    ...After some good discussion on the LLVM mailing list, I realized
    that with a simple registration process, statically initialized info
    structures could be registered by pre-existing drivers. This would
    obviously eliminate the need to read the config file for every
    compilation.<br>
    <br>
    Thanks for the input!<br>
    <br>
    -Rich<br>
    <br>
  </body>
</html>