[cfe-dev] RFC: Clang driver redesign

[Matthieu Monrocq]

Le 4 novembre 2011 15:55, Sean Hunt <scshunt at csclub.uwaterloo.ca> a écrit :

> On Fri, Nov 4, 2011 at 07:11, James Molloy <james.molloy at arm.com> wrote:
> > Usecase 3: Clang developer, developing
> > --------------------------------------
> >
> > Wants no functionality to change - things keep working as normal [1]
> >
> > Usecase 4: Apple/Darwin developer, using fat binaries
> > -----------------------------------------------------
> >
> > Requires fat-binary support. This entails multiple "-arch" arguments
> > being supported. [1]
> >
> > .. note::
> >
> >    Describe this some more?
> >
> > Functional requirements
> > =======================
> >
> > The following requirements follow from the use cases above and attempt
> > to formalise those use cases more precisely.
> >
> > [1] No functional regressions
> >  The driver **must** be able to be configured such that it can parse
> >  command lines that the current Clang driver accepts. The driver
> >  **must** invoke all subtools in the same manner as the current Clang
> >  driver, with the possible exception of obtuse, undefined, legacy or
> >  otherwise incorrect behaviour, permission for which must be obtained
> >  from the mailing list and documented in a subsection of this
> >  document for decision tracking.
>
> I honestly have to disagree with this one. A lot of the reasons for
> horribleness in the current driver is compatibility with GCC. I
> believe that we should really have two drivers, one being the 'nice'
> driver, and one being the compatibility driver. To be honest, I
> consider POSIX specifications for CC rather irrigating as well, but
> I'm willing to concede POSIX compatibility. Naturally, it should be
> easy for these to both be changeable at once so that we don't have
> ridiculous levels of maintenance being performed, but I'm of opinion
> that the current model is predicated on enough levels of annoyances
> that trying to promote a compatible compiler is not a good approach
> (the first example that comes to mind is -Wall).
>
> I'm sure people will disagree with me, though.
>

I fully agree.

I've tried adding options, in the past, and the seggregation of options is
quite... baffling. Some `-fXXX` will influence LLVM while others influence
Clang !?!

The dual Options.td cc1Options.td is quite nice too...

The GCC compatibility is great for a drop-in replacement, but I certainly
see no harm into building a "pure" clang driver, where options are
seggregated according to Clang usecases.

This would also allow implementing a *sane* option syntax, like for example
a hierarchical option parser:

--codegen-stackframe-limit=50

Where "stackframe-limit=50" is dispatched to the "codegen" plugin, which
itself dispatch "limit=50kB" to its stackframe object, which sets its
"limit" attribute to 50000 (for example).

This make it easy to:
- group options right where they are used
- avoid name collisions
- have plugins register their own set of options

I have been working on such a parser in my spare time, and I don't mind
giving the code away as a basis:
=> automatic handling of Integers, Strings, and Enums (which must provide
some specific functions for conversion and listing the available values)
=> automatic handling of Booleans arguments (at the moment, I use =yes or
=no, but it would be trivial to parse --no- as meaning =no providing that
no plugin tries to grab the "no" namespace)

Ah, and I also have a configuration file parser which sets the options
objects before the command line is parsed... (modelled after the config
python module)


>
> > [3] Extensibility
> >  All parts of the driver that are to interact with outside
> >  environment (such as interpreting command lines and launching
> >  subtools) **must** be able to have their behaviour easily modified.
> >
> >  While there is no requirement for this to be able to be done with no
> >  source changes, there **could** be scope for allowing dynamically
> >  loadable modules (in the spirit of ``opt -load``) to change the
> >  driver's behaviour at invoke-time.
>
> Oh no, spec files. ;)
>
> Sean
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111104/7ccc0f92/attachment.html>