<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 14, 2015 at 12:39 PM James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This seems to be a very similar discussion as was just had about triples.<div><br></div></div></blockquote><div><br></div><div>*sigh* :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></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></blockquote><div><br></div><div>Which is done by code changes at the moment, see darwin. (This is not an endorsement, just a statement.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></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></blockquote><div><br></div><div>I hate saying this, but I could use some examples here. This is one of the places that Daniel and I disagreed I think, or at least things like "I have command line options" here makes sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></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></blockquote><div><br></div><div>Possibly. I can still see people wanting to set defaults that are _more_ than the triple, but not different than the triple.</div><div><br></div><div>Example (using gcc build parlance for now):</div><div><br></div><div>configure --target=i386-pc-linux-gnu</div><div><br></div><div>ok, so this is pretty lame. It doesn't even have cmov instructions right? So let's add a -march= flag to all of our compiles.</div><div><br></div><div>That said, it's pretty simple just use configure --target=i586-pc-linux-gnu to solve this, or (for gcc) to use --with-arch which, effectively, does the same thing.</div><div><br></div><div>For clang though we don't have the idea that the compiler is only targeting one thing and so it's both easier and a little more complicated.</div><div><br></div><div>We don't have to worry about compile time configuration, but making sure the compile time options are correct for the platform and handled well is pretty specific. A specific triple for the baseline stuff like arch and environment will work like it does above, however, additional command line options don't so much.</div><div><br></div><div>More below.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></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></blockquote><div><br></div><div>Yes. I am absolutely and unequivocally against this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></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></blockquote><div><br></div><div>I'm not a huge fan of this design, but I think Renato has something that on first glance seemed reasonable. See the message to (I think) llvm-dev or cfe-dev that was sent earlier this week and it has a link to Renato's idea here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></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></blockquote><div><br></div><div>I misread this the first time, but if you're talking about something like:</div><div><br></div><div>clang -spec=/path/to/blah</div><div><br></div><div>we've talked about that in the past as not being terrible.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></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></blockquote><div><br></div><div>As someone who had to hack on spec files a lot I'd prefer not to go the full route for sure. In particular a feature I don't want to support is command line translation at the moment.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><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></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 14 October 2015 at 18:23, C Bergström <<a href="mailto:cbergstrom@pathscale.com" target="_blank">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>
</blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">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></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">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>
</blockquote></div></div>