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

Eric Christopher echristo at gmail.com
Mon Sep 8 11:32:16 PDT 2014


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>


More information about the llvm-dev mailing list