[LLVMdev] Compiler Driver [high-level comments]

[Chris Lattner]

On Wed, 28 Jul 2004, Reid Spencer wrote:

> > 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.

That's orthogonal to the discussion, but my current thought is that no -O
option should default to the equivalent of -O1 or maybe -O2.  A lot of
people just simply "forget" to use -O options and we want to do reasonably
well, but not be too clever :)

> > llvmgcc X.c -On -S # "no" optimization, emit a 'raw' .ll 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?

My thought is that -On is the straight output from the front-end.  -O0
would be the fastest possible compile-time.  These are almost certainly
different, as simple optimizations like DCE can reduce compile times by
reducing disk I/O.  -On would probably only be useful to compiler people.

> > 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).

Yes, sorry, ok s/llvmgcc/driver/

> 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?

Again, whether or not to generate native code is another orthogonal issue,
but one that may be tied into the -O options (e.g. produce native code at
levels -O2 and below).  When generating native code, the compiler driver
would run llc and gas as appropriate.  Of course some day we will be able
to write .o files directly, so we can skip a step. :)

> > 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.

I would thinking -constprop -simplifycfg -mem2reg -dce, though that's
just a first thought :)

> 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 ?

-E should continue to be a preprocessor flag.  We're really talking about
controlling the amount of optimization here, which is why I like the idea
of -On.

> > Anyway, these are just some high-level ideas.
>
> Your thoughts, if any on the other topics would be very much
> appreciated.

Sure.  I'm suprised noone else has chimed in :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://nondot.org/sabre/