[cfe-dev] RFC: Clang driver redesign

[Andrew Trick]

On Nov 7, 2011, at 8:02 AM, Douglas Gregor wrote:
>> 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).
> 
> 
> GCC compatibility is and has always been crucial to the viability of Clang, *especially* in the driver, which needs to deal with many years of accumulated cruft in makefiles and command lines. Unlike with language compatibility, where we can differ from GCC to better adhere to a language standard, GCC's driver *is* the standard for most *nix systems out there. You won't win the hearts and minds of users if you tell them to change all of their makefiles before they can even try Clang.
> 
> By all means, please make it easier to build and distribute cross compilers, but any Clang driver that does not provide GCC compatibility is likely to be a non-starter [*].

This isn't completely true. gcc is the standard for building *open
source packages* across platforms, which has only become important
recently. Your conclusion is correct that tweaking Makefiles cannot be
a requirement for adopting clang. But the assumption that most users
are gcc option gurus is wrong, and clang suffers from that mentality.

The majority of users, build maintainers, need some superficial level
of compatibility. As long as the build doesn't break, they're happy.

The details of invoking subtools, diagnostics, fine control of
optimizations, and target specific flags are important to hackers
who are already dealing with something broken or requiring
extraordinary optimization. Then there are the people on this list,
who simply want to waste less time repeating the horrible
trial-and-error process that it takes to reproduce a problem or enable
an experimental feature. Our experience matters too.

My own experience parallels the community in general. I've used gcc
far more than any other compiler and always appreciated having it when
I need to port a missing library. But I never cared about tweaking any
command line options other than "-g -O0". For any real compiler
development, performance work, or debugging I used the platform
vendor's native compiler which always had a sane, well documented
option set. Very un-like gcc.

My experience adopting a mostly undocumented and seemingly
obfuscated clang driver for development was violently traumatic and
still causes me grief. I'm guessing there are two reasons: (1) the
assumption that all compiler developers must have been gcc/llvm-gcc
developers at some point (2) the evil idea that a driver should be
designed primarily to prevent build engineers from using anything
beyong the minimal option set, which results in burying the rest of
the functionality in an indecipherable web of driver code.

Moving to a driver that compartmentalizes gcc compatibility would be
fantastic. We could finally focus on providing a sensible command-line
interface for the clang community. I'm not necessarily advocating two
drivers so much as a clear and formal segregation between
first-class clang options and gcc compatibility options. This is sort of
the intent behind the unfortunate "-cc1" and "-mllvm" flags. But they
only add considerable confusion from my point of view.

And while I'm in evangelism mode, we need a strict requirement that
every decision within the compiler that can be impacted by the
environment, including target data and library versions, should be
formalized and captured by an option framework. These options
could be either printed and replayed on the command line or potentially
embedded in bitcode. I have no problem disabling these options in
release builds if that's really the way to solve the inertial-QA-team problem.

And how difficult would it be to record those options + compiler version
in the obj file? Really!

Taking it one step further, we should have a single driver that
supports decomposition of the major compilation stages. For example,
I'm currently unable to use basic codegen diagnostics without
hand-inserting instrumentation because I often can't force the llc
driver to produce the same code as the clang driver.

Believe me, experimental compiler development doesn't need to be this
difficult.

-Andy