> 2. MODE OF OPERATION
> ====================
> The driver will simply read its command line arguments, read its
> configuration data, and invoke the compilation, linking, and
> optimization tools necessary to complete the user's request. Its basic
I'm not sure that I agree with this. Compilers need to be extremely
predictable and simple. In particular, saying:
llvmgcc x.c y.c z.c
should invoke exactly the same tools as:
llvmgcc x.c -c
llvmgcc y.c -c
llvmgcc z.c -c
llvmgcc x.o y.o z.o
I don't necessarily think that you're contradicting this, I just wanted to
make sure we're on the same page.
I'm not contradicting anything here. The driver will select a completely
deterministic, simple, and direct sequence of commands in a well defined
order. My analogy to the SQL query optimizer was just that: an analogy.
Its not going to look for the "best" solution, it'll just be coded with
the best strategies built in and completely predictable from there.
> 4. SIMILAR OPTIONS AS GCC
> =========================
> Certain common GCC options should be supported in order to make the
> driver appear familiar to users of GCC. In particular, the following
> options are important to preserve:
Very important, I agree.
> Additionally, we should have options to:
> * generate analysis reports ala the LLVM analyze tool
I'm not certain how useful this would be. It would add complexity to the
driver that is of arguable use. If anything I would make this the last
priority: the people who use 'analyze' are compiler developers, not end
users.
True, I'll drop it.
> 5. BASIC/STANDARD COMPILATION TASKS
> ===================================
> The driver will perform basic tasks such as compilation, optimization,
> and linking. The following definitions are suggested, but more could be
> supported.
There has been a lot of discussion/confusion on IRC relating to what
actually will go into .s or .o files. In particular, some people were
arguing that if we output a .o file, that it should only contain native
code. This means that these two commands would do very different things:
llvmgcc x.c -o x.o # compile to native .o
llvmgcc x.c -o x.bc # compile to bytecode
I have to say that I *strenuously* object to this behavior. In
particular, this would require all users to change their makefiles to get
IPO/lifelong optzn support from LLVM, violating one of the main goals of
the system.
There are a couple of things that people brought up (including wrapping
.bc files in ELF sections, generating .o files containing native
code+.bc), but here is the proposal that I like best: 
I don't think that anything should change w.r.t. the contents of .o files.
In particular, .o files should contain LLVM bytecode without wrappers or
anything fancy around them. The big problem with this is compiler
interoperability, in particular, mixing .o files from various compilers
(e.g. a native GCC) will not work (e.g. 'ld' will barf when it hits an
LLVM .o file).
Personally I don't see a problem with this. We already have "llvm aware"
replacements for many system tools, including ld, nm, and a start for ar.
These tools could be made 'native aware', so that 'llvm-ld x.o b.o' would
do the right thing for mixed native and llvm .o files. Imagine an
llvm-objdump tool that either runs the native objdump program or llvm-dis
depending on the file type.
Okay, above is agreed.
The one major thing that I want to fix is the current kludge of using
llvmgcc -S or llvmgcc -c to control whether the compile-time optimizer is
run. The only reason we did this was because it was easy, and a new
compiler driver is exactly what we need to fix this. In particular, I
would really like to see something like this:
llvmgcc X.c -S # compiles, runs gccas, emits an *optimized* .ll file
llvmgcc X.c -c # Same as -S, but now in .bc form instead of .ll form
Okay, but what's the default -Ox option that gets applied? -O2? -O1?.
Its not clear from this what the default is. To mimic GCC, such a
command line would produce very little, if any optimization.
llvmgcc X.c -On -S # "no" optimization, emit a 'raw' .ll file
llvmgcc X.c -On -c # "no" optimization, emit a 'raw' .bc file
That's fine, -On, I suppose is basically "absolutely no optimization
passes" but what is -O0 (oh zero)? a synonym for -On? Some minimal
optimization?
Basically, today's equivalents to these are:
llvmgcc X.c -c -o - | llvm-dis > X.s
llvmgcc X.c -c
llvmgcc X.c -S
llvmgcc X.c -S -o - | llvm-as > X.o
Are these supposed to match the four above? The use of llvmgcc is
confusing me here. In future discussion, when you mean the future
driver, please write as "driver" (or the actual name if its decided by
then).
So one problem with this is that there's no way to emit a native .o
file? I thought one of the goals you wanted for the driver was to allow
an invoked compiler tool to generate as much as possible, including
native object file (.o) such as ELF. This would imply from the last
example that:
driver X.c -On -c would produce:
llvmgcc X.c -S -o - | llvm-as | llc | gas > X.o
But, your scheme doesn't seem to permit this?
The ability to capture the raw output of a front-end is very useful and
important, but it should be controlled with -O options, not -S/-c. Also,
llvmgcc -O0 is not necessary the same as -On, because some optimizations
actually speed up compilation (e.g., dead code elim).
Okay, you answered my question above. Perhaps you can define the
specific passes that should be included n -O0.
As for capturing the raw output of a front-end, GCC has the -E option
(well, at least for the pre-processor). Do we want to do that ?
Anyway, these are just some high-level ideas.
Your thoughts, if any on the other topics would be very much
appreciated.
Thanks,
Reid.
