llvm dev - Aug 2013 - [LLVMdev] Command line options being put in Target backend libraries

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

Ping ?

On 7/26/2013 6:03 PM, Shankar Easwaran 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

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
<shankare at 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
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130823/73f860ae/attachment.html>

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
> <shankare at 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
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>
http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>

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

On Fri, Jul 26, 2013 at 4:03 PM, Shankar Easwaran
<shankare at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130823/f9c130d9/attachment.html>