[LLVMdev] Compiler Driver [high-level comments]

[Vikram Adve]

I just had a chance to read some of follow-up comments on Reid's 
initial document.  I agree with Chris's discussion below of what is 
needed for users to get IPO/lifelong opt'n via LLVM without extensive 
changes to Makefiles, and about what .o files should contain.  This is 
in perfect agreement with what I just said about how users should view 
LLVM.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/

On Jul 28, 2004, at 1:26 PM, 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.
>
>> 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.
>
>> * have a "no op" mode like -v where it just reports what it would do
>> * have a language specific help utility based on suffixes. For 
>> example,
>>   --help ll would list the options applicable to *.ll input files. 
>> This
>>   would extend to source languages too (e.g. --help c for C help or
>>   --help f for FORTRAN help). The generated help info would be 
>> specific
>>   for the given language, after the config files have been read thus
>>   allowing the output to vary depending on the driver's configuration.
>> * Support the -- option to terminate command line options and indicate
>>   the remaining options are files to be processed. This
>> * Support command line configuration (override config files on the
>>   command line) either by specifying a config file or using special
>>   configuration options.
>> * each option should have short (-X) and long (--language) variants
>
> Sure.
>
>> 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.
>
>
> 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
> llvmgcc X.c -On -S # "no" optimization, emit a 'raw' .ll file
> llvmgcc X.c -On -c # "no" optimization, emit a 'raw' .bc file
>
> 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
>
> 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).
>
> Anyway, these are just some high-level ideas.
>
> -Chris
>
> -- 
> http://llvm.cs.uiuc.edu/
> http://nondot.org/sabre/
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5895 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040803/93d28e6f/attachment.bin>