<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 14, 2017 at 3:08 PM, Hal Finkel via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    </span><span class="gmail-"><blockquote type="cite"><div dir="ltr"><div><div>2. More elaborated solutions</div>
          <div><br>
          </div>
          <div>Many are of opinion that config file in this form is too
            primitive solution, for instance:</div>
          <div>- A good solution must be able to deduce target from
            arguments (-m32),</div>
          <div>- Any workable config-file scheme *must* interact with
            the various target specification command-line arguments, and
            allow for setting options dependent upon the
            actually-selected target,</div>
          <div>- Config file must reduce complexity of clang driver.</div>
          <div><br>
          </div>
          <div>The presented implementation of config files is only a
            way to specify set of options, it cannot solve these
            problems. However it can be extended in future so that, for
            instance, the following construct could be allowed
            (particular syntax does not matter):</div>
          <div><br>
          </div>
          <div>    …</div>
          <div>    #if (argv.contains("-m32"))</div>
          <div>    -target i686-unknown-linux-gnu</div>
          <div>    #else</div>
          <div>    -targer x86_64-unknown-linux-gnu</div>
          <div>    #endif</div>
          <div>    …</div>
          <div><br>
          </div>
          <div>This syntax would require to support `if/else/endif`
            control construct, and builtin function `argv.contains`.
            Ability to include an option conditionally is likely to be
            sufficient to solve large part of the problems mentioned
            above and can indeed reduce complexity of the driver.</div>
        </div>
      </div>
    </blockquote>
    <br></span>
    This is appealing, but I think that we really need to be careful
    here. We don't want to create a system where people are encouraged
    to replicate complex driver logic in the config files in order to
    independently figure out which features might be enabled. Of course,
    we already do this, but the logic ends up in wrapper scripts (and is
    just as likely to be broken, if not more so). However, if we're
    going to create a solution here, we should do so in a way that does
    not encourage the confg-file writer to duplicate driver logic.</div></blockquote><div><br></div><div> </div><div>I'd really like to at least have a *design* for how this can eventually incorporate target-specific options before moving forward with adding a --config option, even if the initial commit won't implement the full design.</div><div><br></div><div>I don't believe hand-wavy "maybe we'll add syntax that looks kinda like a comment so older versions will ignore it" is good enough there.</div><div><br></div><div>I'd like to again keep in mind the use-case I mentioned a while ago. Approximately every linux distro configures GCC to set their default target cpu levels. E.g., Debian seems to set the following:</div><div>- On x86, the default CPU should be i686.</div><div>- But on x86-64, the default CPU isn't changed (aka it's left as "x86-64").</div><div>- For ppc32/ppc64, the default CPU should be power7 but tune for power8.</div><div>- For ppc64le, the default CPU should be power8.</div><div>- On ARM (hf), armv7-a should be the default cpu, vfpv3-d16 the default fpu, and it should default to thumb mode.</div><div>etc...</div><div><br></div><div>Note that those defaults are different on different releases of the distro.</div><div><br></div><div>The way you do this with GCC is via options passed to the configure script: --with-arch-32= --with-arch-64= --with-fpu= --with-mode= etc. which turn into values used in the target-specific OPTION_DEFAULT_SPECS macro. Since GCC only builds for one target at a time (or two, if you count 32/64 separately), and you're expected to need to build a new gcc any time you want to cross-compile, that's sufficient.</div><div><br></div><div>Clang is intrinsically a cross-compiler, so gcc's solution isn't good enough for clang (nor is clang's current behavior enough). So, what's the plan to actually solve this?</div><div><br></div><div>1. There needs to a way to be able to configure the defaults for all supported architectures of the platform (either in a single config, or in multiple that clang knows how to select).</div><div><br></div><div>2. Those platform defaults should, somehow, avoid interfering with the use of clang to cross-compile TO a different platform, and be easy to use FROM a different host platform. (find default config via sysroot, maybe?)</div><div><br></div><div>3. How do we recommend users select a target?<br></div><div>Do we need to look for the proper defaults when the user specifies "--target $TARGET" to clang?</div><div>Or maybe we favor of the "$TARGET-clang" symlink method?</div><div>Or maybe "--target" is a low-level feature not recommended for end-users, and we should steer people to using something like "-arch", to select a named architecture within the current platform configuration, like apple does with darwin-based platforms now?<br></div><div><br></div><div>Again, I'm not saying the first patch needs to implement everything, but I do think a design should exist on how this is going to work.</div></div></div></div>