<div dir="ltr">This seems to be a very similar discussion as was just had about triples.<div><br></div><div>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.</div><div><br></div><div>Here, we have the same exact thing, only a distributor wants to have clang default to -rtlib=compiler-rt.</div><div><br></div><div>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.<br></div><div><br></div><div>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?</div><div><br></div><div>I certainly agree with all the statements that compile-time configuration of this should be very much discouraged. </div><div><br></div><div>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.</div><div><br></div><div>E.g. lib/clang/$VERSION/driver-config.txt might contain something like this:</div><div><br></div><div>DefaultTriple: i386-linux-gnu</div><div>AddFlags: i386--linux-* -march=i686</div><div>AddFlags: *--linux-* --rtlib=compiler-rt --stdlib=libc++</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 14, 2015 at 2:22 PM, Renato Golin via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 14 October 2015 at 18:23, C Bergström <<a href="mailto:cbergstrom@pathscale.com">cbergstrom@pathscale.com</a>> wrote:<br>
> *some* default is already being decided.<br>
<br>
</span>Yes, that's true. But here's the problem: In itself, it's true that<br>
you can do it that way. GCC is proof that is not only doable, but<br>
works "well" for their use case.<br>
<br>
But Clang's design, and LLVM overall is that the back-ends are not<br>
special, nor should have a direct relationship with any specific<br>
front-end. Another core design is that LLVM is a library, and as such,<br>
should be used where possible to avoid code duplication and wrong<br>
decision making.<br>
<br>
In *many* cases, this is broken in Clang's driver. The fact that Clang<br>
has a different mechanism to infer about the targets is the worse of<br>
them, IMO. This is what changes to the Triple, parsers, Tuple are<br>
trying to solve, and they are orthogonal to this issue. The second<br>
worse (in my book), is that the mechanism for choosing libraries is<br>
completely broken. Choosing the default doesn't fix that, just covers<br>
it up, but lets have it as a poor man's fix for a complex problem.<br>
<br>
There are two proposals, and the cut is not perfectly clear, but good<br>
enough for me. I explain:<br>
<br>
1. Make Time Selection: Stick some CMake magic like GCC and simplify<br>
the default-selecting mechanism.<br>
- Pros: very simple to implement, very efficient in LOCs vs.<br>
functionality, low impact on existing builds<br>
- Cons: need to duplicate the testing matrix (I don't want to break<br>
your stuff), steers away from one of Clang's core design decisions<br>
(see above)<br>
<br>
2. Run Time Selection: Create new toolchains, select it with a new triple:<br>
- Pros: follows one of Clang's core design decisions (see above),<br>
allows us to have multiple toolchain decisions based on run-time<br>
arguments (triple), additive testing<br>
- Cons: it's not simple nor cheap to implement, adds non-existing<br>
triples which may play badly with some environments, breaks<br>
compatibility with GCC<br>
<br>
The strongest factor here is the core design of Clang, which gives a<br>
huge start for option 2. The other smaller points may have different<br>
importances, but all of them flatten next to the design argument.<br>
Being them of similar number on both sides, I think they're not strong<br>
enough to move us strongly towards either direction, thus, the<br>
solution 2 is a clear winner.<br>
<br>
Makes sense?<br>
<br>
cheers,<br>
--renato<br>
<br>
PS: To answer the specific question about test duplication: if we add<br>
a triple, we only need to duplicate the specific tests. If you have to<br>
build different compilers, you'll end up running the whole check-all,<br>
test-suite, benchmarks, most of what will be identical.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>