[LLVMdev] Compiler Driver [high-level comments]

[Reid Spencer]

On Wed, 2004-07-28 at 11:26, Chris Lattner wrote:
> On Wed, 28 Jul 2004, Reid Spencer wrote:
> > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040728/368cd726/attachment.sig>