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

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

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.

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.

On 11 August 2012 17:37, Chris Lattner <clattner at apple.com>
wrote:
> Ok, please chat with Daniel Dunbar and Chad Rosier about this.  They'll
definitely have opinions :)
Salvatore is also trying to do this, maybe he has some input.

-- 
cheers,
--renato

http://systemcall.org/

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