llvm dev - Sep 2014 - [LLVMdev] [cfe-dev] RFC: Another go at a cross compiler config file.

> On Sep 8, 2014, at 10:14 AM, Joerg Sonnenberger <joerg at
britannica.bec.de> wrote:
> 
> On Fri, Sep 05, 2014 at 09:23:34PM -0500, Richard Pennington wrote:
>> Right now it only handles replacing a "-target foo" option
>> with the options defined in the file foo in the resource/config
>> directory, but I think it has potential for doing quite a bit more.
> 
> Please don't overload the -target option like that, but make it a
> separate option.
I disagree. One of the problems with clang’s driver now is that we have such a
long list of built-in targets. From the user’s point of view, whether the target
settings come from a yaml file or from hardcoded logic in the driver should be
an implementation detail. It would be great if we could default to specify _all_
targets like this, and then choose which targets to build into the driver based
solely on performance. (It will be a while before any mechanism like this can
support all the features for some of the more complicated targets, so I’m not
proposing that we completely switch to that approach now, but I would like to
see us move in that direction.)

On that note, Richard, do you have any thoughts on how we could support building
these yaml specification into the driver? It seems like many of the targets that
are currently hardcoded could be handled with this approach, but the
compile-time cost of reading a separate yaml file would be unacceptable in some
situations.

—Bob

On Mon, Sep 08, 2014 at 10:59:17AM -0700, Bob Wilson
wrote:
> 
> > On Sep 8, 2014, at 10:14 AM, Joerg Sonnenberger <joerg at
britannica.bec.de> wrote:
> > 
> > On Fri, Sep 05, 2014 at 09:23:34PM -0500, Richard Pennington wrote:
> >> Right now it only handles replacing a "-target foo"
option
> >> with the options defined in the file foo in the resource/config
> >> directory, but I think it has potential for doing quite a bit
more.
> > 
> > Please don't overload the -target option like that, but make it a
> > separate option.
> 
> I disagree. One of the problems with clang’s driver now is that we have
> such a long list of built-in targets. From the user’s point of view,
> whether the target settings come from a yaml file or from hardcoded
> logic in the driver should be an implementation detail. It would be
> great if we could default to specify _all_ targets like this, and then
> choose which targets to build into the driver based solely on
> performance.
Whether it is reasonably possible for such a transistion has to be seen.
If you look at the target logic in the driver, you will seen that
estimated 70% of the complexity is related to Linux, maybe 10% each to
Darwinish systems and Windows and the rest for all other targets
together. So while this can greatly simplify the maintainance cost and
overall code size for Linux, it createse a complexity regression for
other systems. That's a good enough reason for my request to keep it
optional. I'm not against this feature -- if it is well done, it can
improve the status quo. But I am against forced overhead for systems
where we don't need it.

Joerg

On Mon, Sep 8, 2014 at 10:59 AM, Bob Wilson <bob.wilson at apple.com>
wrote:
>
> > On Sep 8, 2014, at 10:14 AM, Joerg Sonnenberger <joerg at
britannica.bec.de>
> wrote:
> >
> > On Fri, Sep 05, 2014 at 09:23:34PM -0500, Richard Pennington wrote:
> >> Right now it only handles replacing a "-target foo"
option
> >> with the options defined in the file foo in the resource/config
> >> directory, but I think it has potential for doing quite a bit
more.
> >
> > Please don't overload the -target option like that, but make it a
> > separate option.
>
> I disagree. One of the problems with clang’s driver now is that we have
> such a long list of built-in targets. From the user’s point of view,
> whether the target settings come from a yaml file or from hardcoded logic
> in the driver should be an implementation detail. It would be great if we
> could default to specify _all_ targets like this, and then choose which
> targets to build into the driver based solely on performance. (It will be a
> while before any mechanism like this can support all the features for some
> of the more complicated targets, so I’m not proposing that we completely
> switch to that approach now, but I would like to see us move in that
> direction.)
>
> On that note, Richard, do you have any thoughts on how we could support
> building these yaml specification into the driver? It seems like many of
> the targets that are currently hardcoded could be handled with this
> approach, but the compile-time cost of reading a separate yaml file would
> be unacceptable in some situations.
>
Right. I was just about to mention this. It has, historically, been a
design requirement of the driver that the load time of a separate file is
unacceptable. A separate option of reading in a file with config data might
be useful in some cases, but I think we should see what the actual use
cases are here first :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140908/e1a122b2/attachment.html>

On 09/08/2014 01:26 PM, Joerg Sonnenberger wrote:
> On Mon, Sep 08, 2014 at 10:59:17AM -0700, Bob Wilson wrote:
>>> On Sep 8, 2014, at 10:14 AM, Joerg Sonnenberger <joerg at
britannica.bec.de> wrote:
>>>
>>> On Fri, Sep 05, 2014 at 09:23:34PM -0500, Richard Pennington wrote:
>>>> Right now it only handles replacing a "-target foo"
option
>>>> with the options defined in the file foo in the resource/config
>>>> directory, but I think it has potential for doing quite a bit
more.
>>> Please don't overload the -target option like that, but make it
a
>>> separate option.
>> I disagree. One of the problems with clang’s driver now is that we have
>> such a long list of built-in targets. From the user’s point of view,
>> whether the target settings come from a yaml file or from hardcoded
>> logic in the driver should be an implementation detail. It would be
>> great if we could default to specify _all_ targets like this, and then
>> choose which targets to build into the driver based solely on
>> performance.
> Whether it is reasonably possible for such a transistion has to be seen.
> If you look at the target logic in the driver, you will seen that
> estimated 70% of the complexity is related to Linux, maybe 10% each to
> Darwinish systems and Windows and the rest for all other targets
> together. So while this can greatly simplify the maintainance cost and
> overall code size for Linux, it createse a complexity regression for
> other systems. That's a good enough reason for my request to keep it
> optional. I'm not against this feature -- if it is well done, it can
> improve the status quo. But I am against forced overhead for systems
> where we don't need it.
I agree that all drivers should not have to pay the overhead of reading 
a file for each compilation. I've updated my blog post with a bit more 
information ( http://ellcc.org/blog/?p=11877). Here's the gist of it:

I use the -target argument, or the prefix on the compiler name, to try 
to open the config file. If a file of that name isn't found, the -target 
argument passes through unscathed and works as it does now. I use YAMLIO 
to read the configuration into a structure...
...After some good discussion on the LLVM mailing list, I realized that 
with a simple registration process, statically initialized info 
structures could be registered by pre-existing drivers. This would 
obviously eliminate the need to read the config file for every compilation.

Thanks for the input!

-Rich

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140908/2e3007ef/attachment.html>