<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 03/16/2017 08:25 AM, Serge Pavlov
wrote:<br>
</div>
<blockquote
cite="mid:CACOhrX4V0OeP2GrnWqOdnA=0wnFech4WCF_SzvPy-Z-nxukhsg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">2017-03-16 9:46 GMT+07:00 James Y
Knight <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span class="gmail-">
<div> </div>
</span>
<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>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
To be clear, there is a current design for this. As Serge mentions
below, we handle PREFIX-clang to search for config files based on
PREFIX. PREFIX here is usually a target, but can be other things as
well for local customization. This was specifically intended to work
for cross compiling. That having been said, we may need to extend
this...<br>
<br>
<blockquote
cite="mid:CACOhrX4V0OeP2GrnWqOdnA=0wnFech4WCF_SzvPy-Z-nxukhsg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Initial versions of this proposal defined two kinds of
config files:</div>
<div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>-
named, which should be explicitly specified by a user by
option --config or be encoded into executable name as
`armv7l-clang`.</div>
<div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>-
default, which is loaded always much like `.bashrc` or any
similar file.</div>
<div>These two kinds of config file shared implementation
but addressed different use cases, which made confusion
during discussion. To facilitate review process the
support of default config files was removed from the
proposal. The issues you mention should mostly be solved
by the default config files.</div>
<div><br>
</div>
<div>If the default config files were implemented in clang,
driver would search binary directory for default
configuration description. If compiler is named as
`armv7l-clang`, driver first tries file `armv7l.cfg` then
`clang.cfg`. If config file is found, options listed there
are put into the set of driver arguments before any option
specified in command line.</div>
<div><br>
</div>
<div>With this feature a distribution or SDK can supply set
of config files as a part of clang package and tunes
compiler appropriately.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Each supported target can have separate config file.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Default config in sysroot could be included by default
clang config, however driver must know where the sysroot
is. We could support a set of macros, for instance expand
`$TARGET` in config file to target name as
`armv7l-clang`. This topic is not elaborated yet.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>To specify a target looks like a more flexible
solution. "$TARGET-clang" symlink method was already
implemented in early versions of <a
moz-do-not-send="true"
href="https://reviews.llvm.org/D24933">https://reviews.llvm.org/D24933</a>.
It is possible also to extend treatment of `--target` so
that it acted similar to `--config`.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
This seems like a good idea. Depending on how the "Linux
distribution" use case actually works (which might also apply to
cross-mounted file systems across different architectures?), we
might also want to also do the search for the default target, even
if none is explicitly provided, so that a distribution can ship a
default set of files and the compiler will pick up the right one for
the current system. James, does this correspond to what you had in
mind?<br>
<br>
Thanks again,<br>
Hal<br>
<br>
<blockquote
cite="mid:CACOhrX4V0OeP2GrnWqOdnA=0wnFech4WCF_SzvPy-Z-nxukhsg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Thanks,</div>
<div>--Serge</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>