[LLVMdev] Command line options being put in Target backend libraries

66 views
Skip to first unread message

Shankar Easwaran

unread,
Jul 26, 2013, 7:03:47 PM7/26/13
to llvmdev Dev
Hi,

I see a lot of command line options being set in Target backend
libraries. The problem with that is if a third party tool links with
Target libraries and has a command line option that needs to be
processed, the option in the Target libraries will get overridden.

$ cd llvm/lib/Target
$ grep 'cl::' */*.cpp --> produces lot of such occurences.

For example :- libLLVMX86CodeGen.a contains
libLLVMX86CodeGen.a:X86RegisterInfo.cpp.o:0000000000000080 b
EnableBasePointer

I think those command line options would need to be moved to the drivers
that are using them, Isnt it ?

Am I mistaken ?

Thanks

Shankar Easwaran

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Shankar Easwaran

unread,
Aug 21, 2013, 11:48:57 PM8/21/13
to llvmdev Dev
Ping ?

Sean Silva

unread,
Aug 23, 2013, 2:41:16 PM8/23/13
to Shankar Easwaran, llvmdev Dev
It is definitely an issue, since the command line options are basically globals, which fundamentally goes against LLVM's library-based design.

-- Sean Silva

Shankar Easwaran

unread,
Aug 23, 2013, 2:56:52 PM8/23/13
to Sean Silva, llvmdev Dev
Hi,

Thanks for your reply, Sean.

I think the reason users arent complaining about this is because, users
dont link with target libraries.

This is going to be a major cleanup too as there have been a lot of
options defined across all the targets.

A simple find/grep shows you a total of 98 options defined in libraries.

Thanks

Shankar Easwaran

On 8/23/2013 1:41 PM, Sean Silva wrote:
> It is definitely an issue, since the command line options are basically
> globals, which fundamentally goes against LLVM's library-based design.
>
> -- Sean Silva
>
>
> On Fri, Jul 26, 2013 at 7:03 PM, Shankar Easwaran
> <shan...@codeaurora.org>wrote:
>
>> Hi,
>>
>> I see a lot of command line options being set in Target backend libraries.
>> The problem with that is if a third party tool links with Target libraries
>> and has a command line option that needs to be processed, the option in the
>> Target libraries will get overridden.
>>
>> $ cd llvm/lib/Target
>> $ grep 'cl::' */*.cpp --> produces lot of such occurences.
>>
>> For example :- libLLVMX86CodeGen.a contains
>> libLLVMX86CodeGen.a:**X86RegisterInfo.cpp.o:**0000000000000080 b
>> EnableBasePointer
>>
>> I think those command line options would need to be moved to the drivers
>> that are using them, Isnt it ?
>>
>> Am I mistaken ?
>>
>> Thanks
>>
>> Shankar Easwaran
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>> by the Linux Foundation
>>
>> ______________________________**_________________
>> LLVM Developers mailing list
>> LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>

Hal Finkel

unread,
Aug 23, 2013, 3:27:23 PM8/23/13
to Shankar Easwaran, Sean Silva, llvmdev Dev
----- Original Message -----
> Hi,
>
> Thanks for your reply, Sean.
>
> I think the reason users arent complaining about this is because,
> users
> dont link with target libraries.
>
> This is going to be a major cleanup too as there have been a lot of
> options defined across all the targets.
>
> A simple find/grep shows you a total of 98 options defined in
> libraries.

I think that we'd need to do a more-careful audit to see how many of these options should really be user accessible. Some of them are there only to enable experimental features or assist target developers with debugging. Nevertheless, we may want to have a more flexible context-based system even for those options.

-Hal
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Eric Christopher

unread,
Aug 23, 2013, 6:33:56 PM8/23/13
to Hal Finkel, Sean Silva, llvmdev Dev
On Fri, Aug 23, 2013 at 12:27 PM, Hal Finkel <hfi...@anl.gov> wrote:
> ----- Original Message -----
>> Hi,
>>
>> Thanks for your reply, Sean.
>>
>> I think the reason users arent complaining about this is because,
>> users
>> dont link with target libraries.
>>
>> This is going to be a major cleanup too as there have been a lot of
>> options defined across all the targets.
>>
>> A simple find/grep shows you a total of 98 options defined in
>> libraries.
>
> I think that we'd need to do a more-careful audit to see how many of these options should really be user accessible. Some of them are there only to enable experimental features or assist target developers with debugging. Nevertheless, we may want to have a more flexible context-based system even for those options.
>

I think we should look into removing them eventually. Structs of flags
or something being passed into the backend might work. Some other
configury mechanism. The cl::opt machinery is great, but quite a bit
abused. I do this myself so I'm not going to throw stones in my glass
house.

-eric

Eli Bendersky

unread,
Aug 23, 2013, 6:41:27 PM8/23/13
to Shankar Easwaran, llvmdev Dev
On Fri, Jul 26, 2013 at 4:03 PM, Shankar Easwaran <shan...@codeaurora.org> wrote:
Hi,

I see a lot of command line options being set in Target backend libraries. The problem with that is if a third party tool links with Target libraries and has a command line option that needs to be processed, the option in the Target libraries will get overridden.

$ cd llvm/lib/Target
$ grep 'cl::' */*.cpp --> produces lot of such occurences.

For example :- libLLVMX86CodeGen.a contains
libLLVMX86CodeGen.a:X86RegisterInfo.cpp.o:0000000000000080 b EnableBasePointer

I think those command line options would need to be moved to the drivers that are using them, Isnt it ?

Am I mistaken ?

Thanks

This is, of course, a problem not only for Target libraries but for other parts of LLVM as well. The cl:: infrastructure, by virtue of its global-ness, allows convenience because options can be added deep inside libraries without too much plumbing. On the other hand, this causes a large number of problems - the one you mention is just one of them.

Eli



 
Reply all
Reply to author
Forward
0 new messages