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

[Renato Golin via cfe-dev]

On 14 October 2015 at 18:23, C Bergström <cbergstrom at pathscale.com> wrote:
> *some* default is already being decided.

Yes, that's true. But here's the problem: In itself, it's true that
you can do it that way. GCC is proof that is not only doable, but
works "well" for their use case.

But Clang's design, and LLVM overall is that the back-ends are not
special, nor should have a direct relationship with any specific
front-end. Another core design is that LLVM is a library, and as such,
should be used where possible to avoid code duplication and wrong
decision making.

In *many* cases, this is broken in Clang's driver. The fact that Clang
has a different mechanism to infer about the targets is the worse of
them, IMO. This is what changes to the Triple, parsers, Tuple are
trying to solve, and they are orthogonal to this issue. The second
worse (in my book), is that the mechanism for choosing libraries is
completely broken. Choosing the default doesn't fix that, just covers
it up, but lets have it as a poor man's fix for a complex problem.

There are two proposals, and the cut is not perfectly clear, but good
enough for me. I explain:

1. Make Time Selection: Stick some CMake magic like GCC and simplify
the default-selecting mechanism.
  - Pros: very simple to implement, very efficient in LOCs vs.
functionality, low impact on existing builds
  - Cons: need to duplicate the testing matrix (I don't want to break
your stuff), steers away from one of Clang's core design decisions
(see above)

2. Run Time Selection: Create new toolchains, select it with a new triple:
  - Pros: follows one of Clang's core design decisions (see above),
allows us to have multiple toolchain decisions based on run-time
arguments (triple), additive testing
  - Cons: it's not simple nor cheap to implement, adds non-existing
triples which may play badly with some environments, breaks
compatibility with GCC

The strongest factor here is the core design of Clang, which gives a
huge start for option 2. The other smaller points may have different
importances, but all of them flatten next to the design argument.
Being them of similar number on both sides, I think they're not strong
enough to move us strongly towards either direction, thus, the
solution 2 is a clear winner.

Makes sense?

cheers,
--renato

PS: To answer the specific question about test duplication: if we add
a triple, we only need to duplicate the specific tests. If you have to
build different compilers, you'll end up running the whole check-all,
test-suite, benchmarks, most of what will be identical.