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

Ping ?

It is definitely an issue, since the command line options are basically globals, which fundamentally goes against LLVM’s library-based design.

– Sean Silva

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

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

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

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