[LLVMdev] Compiler Driver [high-level comments]

[Vikram S. Adve]

On Aug 3, 2004, at 11:46 PM, Reid Spencer wrote:

> On Tue, 2004-08-03 at 14:53, Vikram Adve wrote:

...

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

I did consider -O0, but unfortunately, -O0 on some compilers is the 
default level of optimization and on others the minimal level, neither 
of which is the same as "no optimization."   I think using a suffix 
that is not a number would be better.  This is not a big deal :)

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

That sounds good to me!  I do think this issue is more important than 
some of the others, so let's make sure to discuss it and get it right.

Thanks!

--Vikram


>
> Reid.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev