[cfe-dev] Small patches to allow fully independent clang/llvm/compiler-rt/libc++

[James Y Knight via cfe-dev]

I don't really think an external Python script is a particularly useful
thing here. Again, the problem I want to see solved is this:
- Debian supports a bunch of architectures.
- The default compiler is GCC right now, and builds a native GCC on each
architecture, with certain ABI/ISA defaults hardcoded. There's also a bunch
of work towards supporting the full set of cross-building gccs for building
every arch from every other arch. These of course will all use the same
defaults for the targets no matter what the host arch.
- It also ships a clang. The clang *doesn't* have the defaults encoded
anywhere.

How to fix that? Two slightly different pieces:
1) How to encode the default options for a trivial default-target compile?
"clang test.c" should Just Work, no extra options needed)
2) How to encode the default options for cross compiles to other
architectures? CC="$DEB_HOST_GNU_TYPE-clang" or alternatively CC="clang
-target $DEB_HOST_GNU_TYPE" should work.

Of course, substitute any other distro for "Debian" in the above, and
they'll have their own, different, defaults. (Of course, for C Bergström's
original problem, rtlib and stdlib).

There's no auto-detectionish stuff here; it's all explicitly defined by the
distribution up front. I also don't see any reason so far that this must be
any more complex than adding implicit extra command-line arguments.

So, why not create an external Driver-Driver? E.g. move "clang" aside to
"clang.real", add a python/shell script named "clang" that adds extra args
as desired? Well, of course you *could* do that, but I think that's both a
cop-out *and* is actually harder to properly implement. Take for example,
an x86-64 host, running a clang that defaults to targetting x86-64. If you
run "clang -m32 foo.c", it must use the proper defaults for i386, not
x86-64. That is: I think the defaults need to be added after calling
computeTargetTriple() to get the "real" triple.

For compatibility with existing infrastructure, I don't think requiring new
(non-triple) names for targets is really feasible. Debian has defined their
list of triples on their distribution and their meaning (
https://wiki.debian.org/Multiarch/Tuples), and those names are what people
expect to target. I believe clang's solution to this problem ought to work
within those definitions, not require new ones.

I could see having a two-level configuration, though. That is, allow named
configurations, separate from the "target" (triple). That doesn't enable
anything new, because you could do that with multiple config files anyways.
But it might be a convenience, to allow putting a bunch of different
systems into a single configuration file.

E.g., a config file could look like this:

{
  "default_config": "Debian",
  "default_target": "mipsel-linux-gnu",
  "config": {
    "config_name": "Debian",
    "triple_config": {
      "triple_match": "mips-*-*-*",
      "add_args": ["-march=mips2"]
    },
    "triple_config": {
      "triple_match": "mipsel-*-*-*",
      "add_args": ["-march=mips2"]
    }
  }
  "config": {
    "config_name": "MyNonGNULinuxDistro",
    "add_args": ["-rtlib=compiler-rt", "-stdlib=libc++"],
    "triple_config": {
      "triple_match": "mips-*-*-*",
      "add_args": ["-march=mips4"]
    }
    "triple_config": {
      "triple_match": "mipsel-*-*-*",
      "add_args": ["-march=mips32r2"]
    }
  }
}

And then:
# Builds for target mipsel-linux-gnu, with args "-march=mips2" implicitly
added from the Debian config.
clang test.c

# Builds for target mips-linux-gnu, with args "-rtlib=compiler-rt
-stdlib=libc++ -march=mips4" implicitly added from the MyNonGNULinuxDistro
config.
clang --config-name=MyNonGNULinuxDistro -EB test.c

# Don't use any configuration-based customizations
clang --config-name=none test.c

I really think something simple like the above would be basically trivial
to implement within clang, and solve the problems people need to have
solved in this area. And there's no need to block on the massive
triple/tuple refactoring, or anything like that.

On Wed, Oct 14, 2015 at 4:57 PM, Renato Golin <renato.golin at linaro.org>
wrote:

> On 14 October 2015 at 21:17, Eric Christopher <echristo at gmail.com> wrote:
> > Thanks for the subject line pointer, this is the thread I meant. I need
> to
> > review the proposal a bit more, but on the surface it seems not-terrible
> :)
>
> Precisely. That's why I want it to be an external Python script for
> now, so we can grow with it, and maybe throw it away if we were
> completely wrong.
>
> We should only change the driver if the Python script ends up being
> most excellent.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151015/08a72b86/attachment.html>