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

[James Y Knight via cfe-dev]

This seems to be a very similar discussion as was just had about triples.

Before, we discussed that Debian has setup their GCC to default to
-march=i586 (and is now planning to switch to i686) for the
"i386-linux-gnu" triple. And even more complicated examples for ARM, and
other systems.

Here, we have the same exact thing, only a distributor wants to have clang
default to -rtlib=compiler-rt.

IMO, the argument that doing this sort of thing is evil and shouldn't ever
be supported, and that there cannot be any distributor customization, is a
dead-end. Distributors *need* the ability to customize this stuff in
existing triples -- somehow. The same triples REALLY DO have different
defaults on different systems...and even on different variants of the
"same" system. We don't want distributors to have to patch the source code
to achieve that -- that's worst of all options.

So to me, the real question is not whether this is needed, but how do we
let people do it in a supportable/testable way?

I certainly agree with all the statements that compile-time configuration
of this should be very much discouraged.

How about, instead, having the clang driver read a config file? The clang
driver could default to reading a location within its install directory
(overridable via command-line option for testing or other such purposes).
The config file might contain something like a list of match criteria for
the triple, and the commandline args to add. Of course, clang can easily
report the arguments that have been added from the config file in any
diagnostic dump, to let anyone else reproduce someone's compilation.

E.g. lib/clang/$VERSION/driver-config.txt might contain something like this:

DefaultTriple: i386-linux-gnu
AddFlags: i386--linux-* -march=i686
AddFlags: *--linux-* --rtlib=compiler-rt --stdlib=libc++

This does add a gotcha for anyone building their own clang from source on
an existing system: they will need to copy the config file over or pass its
path on the command-line to get the same behavior as the system compiler.
That is certainly a downside, but to me it seems a worthwhile idea anyways.

Of course, this sort of thing starts to feel like a GCC spec file, and
those are totally craaaaaazy! But, since we don't need to make this be a
super-general system for configuring the behavior of EVERYTHING including
the way internal bits and pieces work together, I'd hope it's possible to
get away with a much simpler config system like the above, versus the much
greater complexity (and power) provided for in a gcc spec file.

On Wed, Oct 14, 2015 at 2:22 PM, Renato Golin via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151014/38b4302a/attachment.html>