[cfe-dev] RFC: Clang driver redesign (round 2)

[Chris Lattner]

On Nov 8, 2011, at 3:23 AM, James Molloy wrote:
> Thanks for all the replies. I've kind of summarised the main points of
> contest so far below and tried to group supporters and opponents. If
> I've grouped you incorrectly, please don't take it slanderously :)

Just MHO:

> "To GCC or not to GCC, that is the question"
> ============================================
> 
> +Doug Gregor, Miles Bader
> -Sean Hunt, Christopher Jefferson, Andrew Trick
> 
> There is differing opinion on the amount of GCC compatability clang
> should offer. A lot of examples and arguments have been given, but I
> see one conclusion - the driver should not be pinned to anything.

This is an absolute must-have.  I guess I'm not opposed to having a *second* driver that is "nicer" somehow than the existing one, but we cannot give up GCC compatibility in the main clang driver.

However, the challenge then becomes "why would anyone use the 'nice' one"?  It is likely to get less development and features, and users of the compiler don't care about academic purity of the implementation details.  Any features of the 'nice' driver would also need to supported by the 'ugly' driver also, so I don't see that introducing a new driver is really all that useful.

Features like better cross compiler support can be cleanly integrated into the current driver, so these seem like orthogonal goals.

> More command line options
> =========================
> 
> +Matthew Monrocq, Ruben Van Boxem, Hal Finkel
> -Eric Christopher
> 
> There were questions as to whether we should allow access to compiler
> internal features or not. My personal opinion is that internal options
> should be exposed both for power users and for remote debugging /
> working around compiler errata before a patch is available.

I tend to prefer very few command line options, but there is a practical limit.  I really don't like the GCC "tuning" options because:

 1) they are unstable (e.g. the units in the inlining thresholds)
 2) they get dropped into makefiles and forgotten / not reevaluated
 3) performance isn't stable across compiler changes / improvements.
 4) every new option is adds to the testing cross product, meaning that new flags are generally quite untested.

> Regardless, this ties in with the GCC question in that the option
> should be there, should we choose to use it policy-wise.

Clang specifically accepts and ignores a lot of GCC options.  This is a feature :).

> Plugins producing non-llvm output
> Driving extra optimizations
> =================================

+1 in the current driver.

> Cross compile toolchain
> =======================

+1 in the current driver.

-Chris