[LLVMdev] Compiler Driver [high-level comments]

[Vikram Adve]

Some additional responses (this covers multiple previous messages):


> As part of my work on bug 353: Create Front End Framework And Compiler
> Driver (http://llvm.cs.uiuc.edu/PR353), I'm starting a discussion on 
> the
> design and requirements of the compiler driver.

Thanks very much for taking the lead on this, Reid.  I think this will 
prove to be a valuable thing and, as you noted, the primary interface 
to LLVM for the end-user.


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

Good decision.  I agree with Chris that this driver should not try to 
do things outside the normal "compile-link-optimize[-codegen]" 
sequence.  Similarly, llvmee should control the 
"[codegen-]run-reoptimize" sequence.

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

I agree, and your list looked good. Some other options to consider are:
   -save-temps              Do not delete intermediate files
   -time                    	Time the execution of each subprocess
   -B <directory>           Add <directory> to the compiler's search 
paths
   -b <machine>             Run gcc for target <machine>, if installed

Some of our current tool options may also need to be in driver:
   -time-passes		Time individual LLVM passes
   -stats			Print pass statistics



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

Yes!


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

I agree.


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

Also, -instcombine?


>
>>> llvmgcc X.c -On -S # "no" optimization, emit a 'raw' .ll file
>
>> That's fine, -On, I suppose is basically "absolutely no optimization
>> passes"

-On seems misleading to me.  It conveys opt. level "n" .  It could also 
be read as "on" (as opposed to "off").   How about -Onone?  As Chris 
pointed out, this is really meant for compiler developers, not 
end-users, so let's make it different from the standard user's scheme 
and clear to boot.


> <configuration name="llvm">
>  <group name=".c">
>    <item name="compile">cc1 %in -o %out</item>
>    <item name="optimize">gccas %in -o %out.bc</item>
>    <!-- ... -->
>   </group>
> </configuration>
>
> I think something like this satisfies all the goals:
> * simple and easy; recursive descent parser is a no-brainer
> * XML format with full DTD (RNG or XML Schema) that can be used by 
> other
>   tools to auto-configure llvmcs
> * structured so we can extend in the future

Reid, while I see the power and extensibility of this, it seems way 
overkill for what the driver will do.  The driver should not be 
replacing Makefiles, which are the way to orchestrate a complex 
multi-step build.  The driver really only ever needs about five steps 
as you described above.  We shouldn't need an extensible markup 
language to specify
	compile = <string>
	optimize intra-module =  <string>
	link =  <string>
	optimize cross-module =  <string>
	codegen =  <string>
XML would make sense if we were trying to configure the pass manager's 
internal operations or customize the running of IPO passes in opt, or 
something like that, which may have multiple complex steps.  The driver 
is the end-user's interface to the llvm system and should err on the 
side of simplicity, not power.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4729 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040803/45b75101/attachment.bin>