[cfe-dev] alternate clang driver

Fri Oct 21 14:47:16 PDT 2011

It's going to be cached by the OS after the first time it's loaded.

On 10/21/2011 02:32 PM, James Molloy wrote:
>> I don't buy the C++ is faster that Python argument.
> Well it is, and with such a small script you pay the large fixed cost of loading the CPython interpreter for almost no runtime.
>
> The fact that the python runtime can boot quicker than you can notice on a modern computer doesn't make it fast, it makes it not *noticably slow* by the purist definition. It would slow down large build systems, and for lots of small compiles may significantly increase the build time and load.
> ________________________________________
> From: reed kotler [rkotler at mips.com]
> Sent: 21 October 2011 22:15
> To: James Molloy
> Cc: Alek Paunov; cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] alternate clang driver
>
> I don't buy the C++ is faster that Python argument. It's just a driver
> for a compiler! You could write it in Turing machine primitives and it
> would be super fast on a modern computer. It's not computing the
> strongly connected components of a terabyte sized graph.
>
> I think you will have some kind of scripting component; whether it's LUA
> or Python or some hand brewed language format that is read by the clang
> driver and then interpreted, that is what you will have when you finish
> solving this problem. That is what I meant by all solutions will be
> isomorphic.
>
> Reed
>
> On 10/21/2011 01:56 PM, James Molloy wrote:
>> Hi,
>>
>> Seeing as everyone's putting in their 2cents, here's mine.
>>
>> The problem is that the current Clang driver is not extensible enough, or easily extensible enough. One can argue that a driver doesn't belong in Clang - that's really arguing semantics because the Driver, while living under the clang tree is detached from the rest of Clang and invokes it as subprocesses.
>>
>> My opinion is that the driver should be either:
>>
>>     * Pure C++/TableGen with pretty much everything declaratively defined and just some C++ glue. OR
>>     * Pure C++, reads some sort of configuration file.
>>
>> The latter allows for distros to more easily adapt Clang without (a) rebuilding it and (b) shoving patches to support their weird directory structure on us.
>>
>> I do *not* think that launching an external scripting language is best for two reasons.
>>
>> Firstly it is slower than pure C++. ("Oh but LuaJIT is fast!", "Oh but Python is fast!", "The driver time doesn't matter!" - it does. Clang has been built around build speed and to clobber all that effort because of laziness in the driver isn't an option IMHO. And interpreters, even LuaJIT, aren't that fast to boot).
>>
>> Secondly because they create an extra dependency which is bad in and of itself IMHO but worse causes real difficulty in the bringup of new, native toolchains. You'd have to somehow cross-compile LuaJIT for your new architecture before you could run a hosted compiler. This is a terrible idea.
>>
>> Reed, to argue that all solutions would be isomorphic to yours is the same as arguing that Python and C are both Turing-complete and so there is no difference in using one over the other.
>>
>> Cheers,
>>
>> James
>> ________________________________________
>> From: cfe-dev-bounces at cs.uiuc.edu [cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Alek Paunov [alex at declera.com]
>> Sent: 21 October 2011 20:46
>> To: Reed Kotler
>> Cc: cfe-dev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] alternate clang driver
>>
>> Hi Reed,
>>
>> I am fully behind your line of thinking, but why not be even one step
>> more "radical" than your first step:
>>
>> XML (or JSON or YAML - some variant of tree with properties as text -
>> never mind, once it is processable) + scripting language which transform
>> the registry to tool invocation parameters.
>>
>> This means just few lines of important scripting code which everyone can
>> modify (in specific cases) and instant understanding of the required
>> data model (because one look at the bundled XML/JSON variants per
>> distribution will be enough for the (even average) developer to realize
>> the actual requirements).
>>
>> I am also long time Linux/Python user, but in my feelings, the best for
>> CLang (because there are other aspects too) at the moment is LuaJIT.
>>
>> Kind Regards,
>> Alek
>>
>> On 21.10.2011 18:51, Reed Kotler wrote:
>>> On 10/21/2011 03:25 AM, David Chisnall wrote:
>>>> On 21 Oct 2011, at 10:30, Jean-Daniel Dupas wrote:
>>>>
>>>>> I'm not sure writing a new driver from scratch is better than trying to externalize the configuration in the current driver.
>>>>>
>>>>> Is there anybody currently working on the universal driver ( http://clang.llvm.org/UniversalDriver.html ) ?
>>>> No one's currently working on it (or, wasn't last week when I asked).  It's on my to-do list, but keeps getting pushed lower down by stuff I actually get paid for...
>>>>
>>>> David
>>>>
>>>> -- Sent from my brain
>>>>
>>> You will see that no matter how you do this, you will ultimately end up
>>> with an isomorphic solution to what I did.
>>>
>>> You could try and put all the configuration variables in an XML file.
>>>
>>> That will be like the data structures in my program but harder to
>>> understand when you want to configure things. You can't factor things
>>> then because it's just a big data file. If you do a lot of factoring,
>>> you won't be able to understand the file after a while without building
>>> some tool.
>>>
>>> There are often some tricky things for a given installation, target,
>>> etc. and it's easier to fix this in the driver script than rebuilding
>>> the front end.
>>>
>>> Dynamic scripting is more natural for handling installation issues than
>>> hard coding it in the compiler or even if you add reading some kind of
>>> external file.
>>>
>>> Right now lots of people have to touch code in the same files for the
>>> driver, always a bad omen and indicator of design flaws and source of bugs.
>>>
>>> What will happen is that over time, people will chip away at this
>>> problem and in the end you will have some half baked scripting language
>>> inside of the driver that does exactly the subset of python needed for
>>> my driver.
>>>
>>> Clang should be a C++/C front end and that's it.
>>>
>>> Let some natural scripting language worrying about gluing other pieces
>>> together.
>>>
>>> My 2c.
>>>
>>> Reed
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
>>
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
>