[cfe-dev] [LLVMdev] [RFC] New command line parsing/generating framework for clang and lld.

[Daniel Dunbar]

On Mon, Aug 13, 2012 at 1:10 AM, James Molloy <James.Molloy at arm.com> wrote:
> Hi Michael,
>
> On Sat, 2012-08-11 at 17:37 +0100, Chris Lattner wrote:
>> On Aug 11, 2012, at 12:03 AM, Michael Spencer <bigcheesegs at gmail.com> wrote:
>>
>> > On Fri, Aug 10, 2012 at 6:28 PM, Chris Lattner <clattner at apple.com> wrote:
>> >>
>> >> On Aug 9, 2012, at 1:26 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:
>> >>
>> >>>> Attached is a patch that adds tools/llvm-cltest. This currently contains code
>> >>>> that should be in a library and will not exist in the final version. This is a
>> >>>> proof of concept for what TableGen would actually generate. It does not contain
>> >>>> the actual TableGen implementation.
>> >>>>
>> >>>> - Michael Spencer
>> >>>
>> >>> ping.
>> >>
>> >> Are you proposing that clang switch over to this, or that this be used solely by lld?
>> >>
>> >> -Chris
>> >
>> > Both clang and lld.
>>
>> Ok, please chat with Daniel Dunbar and Chad Rosier about this.  They'll definitely have opinions :)
>>
>> -Chris
>>
>>
>
> Sorry for the late response. I don't feel I'm the best person to comment
> on this because of my aborted attempts and broken promises at improving
> the driver, but you did add me on cc... :)
>
> I like the general idea. But why is this idea so removed from the
> current (rather heavyweight) Clang argument parsing library that it
> needs a full rewrite?
>
> I get that moving the argparse stuff out of the driver is a good idea so
> other tools can use it, but does it need to be reengineered so heavily?
>
> For example, 4/5 of your "scope" points can be handled by the current
> library architecture with perhaps a few implementation additions (typo
> correction, for example).
>
> It's just transforming arguments from one tool to another that isn't
> implemented.
>
> How do transformations fit in with CompilerInvocation?
>
> As a sidenote, I've never understood why we distinguish between joined
> and separate arguments. Are there situations where is it useful to
> disambiguate between them? I'm always annoyed that clang will accept
> "-mcpu=X" but not "-mcpu X". It seems a pointless feature to me.

It is, but its also a compatibility point with GCC. That at least is
the reason why it works the way it does. For this specific case, one
might imagine it could be cleaned up without breaking anything
serious, but its a lot of work for little gain IMHO given that in
general there are many other areas where the GCC style option syntax
doesn't make sense, and we can't fix without breaking compatibility.

 - Daniel

> Many tools take very similar arguments. For example, GCC, Clang, As and
> Ld all take the "-mcpu" option. Does this need to be specified again for
> every tool? There doesn't seem to be a method of inheritance of options.
>
> I like your transformation idea though - I had a similar idea back last
> January but it was more along the lines of a compiler "pass" like
> architecture than fully tablegenned. I like it.
>
> These are my initial comments from a quick scan-read - apologies if I've
> misunderstood anything significant :)
>
> Cheers,
>
> James
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev