[LLVMdev] Patch: Prefix for ParseCommandLineOptions()

[Chris Lattner]

On Mar 4, 2009, at 12:15 AM, Alexei Svitkine wrote:
> I was thinking about this more, and perhaps a more preferable solution
> would have some kind of OptionGroup parameter to constructors of cl
> options. This would of course be optional, with the default being a
> global one.

Hi Alexei,

Sorry for the delay, I've been swamped lately and tend to process  
email in LIFO order :(

> Then, ParseCommandLineOptions() could instead take as an optional
> parameter an OptionGroup, and would then only work on cl options in
> that group. Would this approach be preferable?

I think that something like this would be a better approach.  There  
are a couple of related issues here:

1. In a tool like llc, I'd really only like "llc -march=x86 --help" to  
show options that make sense for the x86 backend.  "llc --help" should  
show *no* target-specific options.  Similarly, opt should only show  
command line options relating to enabled optimizers.

2. A tool that embeds LLVM may not want the LLVM options to be exposed  
through to its command line interface (your case).

To solve #1, we would have to add a predicate member to cl::opt's that  
are called to determine whether they are enabled.  Dependent options  
could then be parameterized appropriately.

For #2, there are a couple of different options with varying levels of  
badness:

1. You could use a compiler driver to handle translation.  This is  
what we do in clang.  In the example of clang, this handles  
translation of things like -msse3 to -mattr=+sse3 for example.

2. You can parse your actual argc/argv list with custom code, then  
assemble an argument list that you pass into the llvm CommandLine  
library to control the optimizer and backend.  This is what the cc1  
commands in llvm-gcc do: they parse the command line with the GCC  
stuff, then assemble an array of strings that gets passed into the  
command line option stuff.

What do you think?

-Chris