[LLVMdev] Compiler Driver [high-level comments]

[Reid Spencer]

On Tue, 2004-08-03 at 14:53, Vikram Adve wrote:
> Some additional responses (this covers multiple previous messages):
> 
> 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.

No problem. Happy to do it. I don't mind improving the edges while your
research crew makes the core better. In the end we all end up with a
better system.

> 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
> searchpaths
>   -b <machine>             Run gcc for target <machine>, if installed

Yes, good points. I'll put these on the list.

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

Yes, those are givens.


> Also, -instcombine?

Okay.

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

Chris and I were debating what -On, -O0 (oh zero) and -O1 were supposed
to mean. The defs of -O0 and -O1 got kinda muddles. I think we should
drop the idea of -On* and just use -O0 to mean "absolutely no
optimization". The default, -O1, would give the "light/fast
optimization" described previously. Since -O0 is somewhat strange, it
reinforces the notion that this option is for front end developers to
use when checking the output of their front end. 

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

While I tend to agree (my first thought was Windows .ini files), some
good points were raised on IRC. First, other tools (e.g. IDEs like
Eclipse) will more naturally be able to parse/generate XML and
integration with those tools is important. Secondly, its not at all
clear to me that the configuration can be as simple as you've described
above. I think we can make the configuration file extremely simple even
if its XML (i.e. only four element names and one attribute name). By
choosing XML we don't have to worry about completely changing the format
should it need to get a little more complicated.

However, what I'd like to do is defer the decision on this until I've
gotten through the feature/design document and its been reviewed. The
details of what goes in a configuration file will be much more clear at
that point and the correct format will most likely present itself.

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/20040803/25feaaa0/attachment.sig>