RFC: Clang driver redesign (round 2)

Clang Frontend
1

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 :slight_smile:

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

2

Ease of use.

I see stories like this over and over again when teaching students.

$ cat test.cc
#include <iostream>

int main(void)
{
Ā Ā int i;
Ā Ā std::cout << i;
}
$ clang test.cc
Undefined symbols for architecture x86_64:
Ā Ā "std::ios_base::Init::Init()", referenced from:
Ā Ā Ā Ā Ā Ā ___cxx_global_var_init in t-vtk1TB.o
Ā Ā "std::ios_base::Init::~Init()", referenced from:
Ā Ā Ā Ā Ā Ā ___cxx_global_var_init in t-vtk1TB.o
Ā Ā "std::cout", referenced from:
Ā Ā Ā Ā Ā Ā _main in t-vtk1TB.o
Ā Ā "std::ostream::operator<<(int)", referenced from:
Ā Ā Ā Ā Ā Ā _main in t-vtk1TB.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
< wander off and ask someone why the code isn't compiling >
$ clang++ test.cc
$ ./a.out
1872097369
< wander off to ask why the code isn't working. Get told to enable warnings >
$ clang++ test.cc -Wall
t.cc:6:16: warning: variable 'i' is uninitialized when used here
Ā Ā Ā Ā Ā Ā [-Wuninitialized]
Ā Ā std::cout << i;
Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā Ā ^
t.cc:5:8: note: initialize the variable 'i' to silence this warning
Ā Ā int i;
Ā Ā Ā Ā Ā Ā Ā ^
Ā Ā Ā Ā Ā Ā Ā Ā = 0
1 warning generated.
< grumbles, add the initialisation, code works>

I think it would be worth trying to reduce the pain here, for a beginner programmer. I'll admit I don't know the best way of doing that.

Chris

3

Give students an IDE, an example Makefile, or Cling?

David

-- Send from my Jacquard Loom

4

You want to reduce the amount of magic you introduce students to at
once, and adding an IDE or build system is more magic.

Sean

5

Yes, I also think that is really annoying and should be fixed. Why does fixing it require a new driver?

-Chris

6

2011/11/9 Chris Lattner <clattner@apple.com>

Yes, I also think that is really annoying and should be fixed. Why does fixing it require a new driver?

-Chris

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 :slight_smile:

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ā€?

Ease of use.

I see stories like this over and over again when teaching students.

$ cat test.cc
#include

int main(void)
{
int i;
std::cout << i;
}
$ clang test.cc
Undefined symbols for architecture x86_64:
ā€œstd::ios_base::Init::Init()ā€, referenced from:
___cxx_global_var_init in t-vtk1TB.o
ā€œstd::ios_base::Init::~Init()ā€, referenced from:
___cxx_global_var_init in t-vtk1TB.o
ā€œstd::coutā€, referenced from:
_main in t-vtk1TB.o
ā€œstd::ostream::operator<<(int)ā€, referenced from:
_main in t-vtk1TB.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
< wander off and ask someone why the code isnā€™t compiling >
$ clang++ test.cc
$ ./a.out
1872097369
< wander off to ask why the code isnā€™t working. Get told to enable warnings >
$ clang++ test.cc -Wall
t.cc:6:16: warning: variable ā€˜iā€™ is uninitialized when used here
[-Wuninitialized]
std::cout << i;
^
t.cc:5:8: note: initialize the variable ā€˜iā€™ to silence this warning
int i;
^
= 0
1 warning generated.
< grumbles, add the initialisation, code works>

I think it would be worth trying to reduce the pain here, for a beginner programmer. Iā€™ll admit I donā€™t know the best way of doing that.

Chris

Loosely related but not completely orthogonal; does LLVM provide an abstracted fool-proof API/Class to gather commandline arguments? Seeing that it provides a bunch of executables and lends itself to fronted development, I would think it should, something simple that reads all the arguments, converts them to some generic/specialized ā€œcommandlineoptionsā€ structure, that the frontend can transparently use to get itā€™s internal options from.

Or am I completely rambling?

Ruben

7

Another requirement for the new driver should be ā€œhow are you going to test the damn thingā€?
That should factor into the design.

I think some kind of simulation mode, i.e. like ā€œmake -nā€ or ā€œmake --just-printā€) should exist so that you can make test cases for this. Then you can capture expected output , etc.

Something more involved where you can provide answers to certain questions the driver will ask of the environment.

This is especially important considering the various platforms and targets.

8

Another requirement for the new driver should be ā€œhow are you going to test the damn thingā€?
That should factor into the design.

I think some kind of simulation mode, i.e. like ā€œmake -nā€ or ā€œmake --just-printā€) should exist so that you can make test cases for this. Then you can capture expected output , etc.

Something more involved where you can provide answers to certain questions the driver will ask of the environment.

This is especially important considering the various platforms and targets.

Something like clang -### ?