[cfe-dev] Configuration files

[Hal Finkel via cfe-dev]

On 03/16/2017 08:25 AM, Serge Pavlov wrote:
> 2017-03-16 9:46 GMT+07:00 James Y Knight <jyknight at google.com 
> <mailto:jyknight at google.com>>:
>
>     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.
>
>     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.
>

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...

>
>     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:
>     - On x86, the default CPU should be i686.
>     - But on x86-64, the default CPU isn't changed (aka it's left as
>     "x86-64").
>     - For ppc32/ppc64, the default CPU should be power7 but tune for
>     power8.
>     - For ppc64le, the default CPU should be power8.
>     - On ARM (hf), armv7-a should be the default cpu, vfpv3-d16 the
>     default fpu, and it should default to thumb mode.
>     etc...
>
>     Note that those defaults are different on different releases of
>     the distro.
>
>     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.
>
>     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?
>
>
> Initial versions of this proposal defined two kinds of config files:
> - named, which should be explicitly specified by a user by option 
> --config or be encoded into executable name as `armv7l-clang`.
> - default, which is loaded always much like `.bashrc` or any similar file.
> 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.
>
> 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.
>
> With this feature a distribution or SDK can supply set of config files 
> as a part of clang package and tunes compiler appropriately.
>
>
>     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).
>
>
> Each supported target can have separate config file.
>
>     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?)
>
>
> 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.
>
>     3. How do we recommend users select a target?
>     Do we need to look for the proper defaults when the user specifies
>     "--target $TARGET" to clang?
>     Or maybe we favor of the "$TARGET-clang" symlink method?
>     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?
>
>
> To specify a target looks like a more flexible solution. 
> "$TARGET-clang" symlink method was already implemented in early 
> versions of https://reviews.llvm.org/D24933. It is possible also to 
> extend treatment of `--target` so that it acted similar to `--config`.

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?

Thanks again,
Hal

>
> Thanks,
> --Serge
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170316/703c0ee0/attachment.html>