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

[Eric Christopher via cfe-dev]

On Wed, Oct 14, 2015 at 12:39 PM James Y Knight via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> This seems to be a very similar discussion as was just had about triples.
>
>
*sigh* :)


> 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.
>
>
Which is done by code changes at the moment, see darwin. (This is not an
endorsement, just a statement.)


> 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.
>
>
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.


> 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?
>
>
Possibly. I can still see people wanting to set defaults that are _more_
than the triple, but not different than the triple.

Example (using gcc build parlance for now):

configure --target=i386-pc-linux-gnu

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.

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.

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.

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.

More below.



> I certainly agree with all the statements that compile-time configuration
> of this should be very much discouraged.
>
>
Yes. I am absolutely and unequivocally against this.


> 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++
>
>
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.


> 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.
>
>
I misread this the first time, but if you're talking about something like:

clang -spec=/path/to/blah

we've talked about that in the past as not being terrible.


> 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.
>

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.

-eric


>
> 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
>>
> _______________________________________________
> 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/32d39843/attachment.html>