search for: parsecommandlineoptions

Hi, I am sending a patch to enable response file support in ParseCommandLineOptions. With this change, all llvm tools will support response file. This helps overcome the command line length limit which we encountered recently. Index: include/llvm/Support/CommandLine.h =================================================================== --- include/llvm/Support/CommandLine.h (revi...

Hi Sam, please add a testcase. Does this cause any regressions? Ciao, Duncan. > I am sending a patch to enable response file support in ParseCommandLineOptions. > With this change, all llvm tools will support response file. This helps overcome > the command line length limit which we encountered recently. > > Index: include/llvm/Support/CommandLine.h > > =================================================================== > > --- in...

...se-files Sam -----Original Message----- From: Matt Beaumont-Gay [mailto:matthewbg at google.com] Sent: Tuesday, October 02, 2012 1:35 PM To: Liu, Yaxun (Sam) Cc: Chris Lattner; llvm-commits at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [llvm-commits] patch to enable response file support in ParseCommandLineOptions Can we call this a "parameters file"? I find "response file" to be non-obvious. On Tue, Oct 2, 2012 at 8:18 AM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > Thanks Chris for the comment. > > > > Since there is no objection, I attached a new patch which...

...a simple test. I did regression check and there are no regressions. + llvmdev Sam From: Chris Lattner [mailto:clattner at apple.com] Sent: Sunday, September 30, 2012 2:20 PM To: Liu, Yaxun (Sam) Cc: llvm-commits at cs.uiuc.edu Subject: Re: [llvm-commits] patch to enable response file support in ParseCommandLineOptions On Sep 21, 2012, at 2:07 PM, "Liu, Yaxun (Sam)" <Yaxun.Liu at amd.com<mailto:Yaxun.Liu at amd.com>> wrote: Hi, I am sending a patch to enable response file support in ParseCommandLineOptions. With this change, all llvm tools will support response file. This helps overcome...

...; > + llvmdev > > > > Sam > > > > From: Chris Lattner [mailto:clattner at apple.com] > Sent: Sunday, September 30, 2012 2:20 PM > To: Liu, Yaxun (Sam) > Cc: llvm-commits at cs.uiuc.edu > Subject: Re: [llvm-commits] patch to enable response file support in > ParseCommandLineOptions > > > > > > On Sep 21, 2012, at 2:07 PM, "Liu, Yaxun (Sam)" <Yaxun.Liu at amd.com> wrote: > > > > Hi, > > > > I am sending a patch to enable response file support in > ParseCommandLineOptions. With this change, all llvm tools will support...

...n behind this patch is that tools that use LLVM as a library and want to use its command line parsing facilities may not want all the various options defined in the LLVM libraries to be available - simply because they may not be relevant. This patch adds an optional "Prefix" parameter to ParseCommandLineOptions(). If set, this will make inaccessible any options that do not begin with the prefix string. Any options with the prefix string will act as if they were defined without that string. For example, if prefix string is "foo-", and "foo-bar" is a defined option, it will be displayed...

...ools that use LLVM as a > library and want to use its command line parsing facilities may not > want all the various options defined in the LLVM libraries to be > available - simply because they may not be relevant. > > This patch adds an optional "Prefix" parameter to > ParseCommandLineOptions(). If set, this will make inaccessible any > options that do not begin with the prefix string. Any options with the > prefix string will act as if they were defined without that string. > > For example, if prefix string is "foo-", and "foo-bar" is a defined > opti...

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. 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? -Alexei On Wed, Mar 4, 2009 at 2:04 AM, Evan Cheng <echeng at apple.com> wrote: > I don't have any opinions about this. Chris? > &...

...On 05/30/16 01:34 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> >> We don't use cl::opt in gold, instead we parse the -plugin-opts that >> gold passes the plugin (see process_plugin_option). >> >> What about that: >> >> $ grep ParseCommandLineOptions tools/gold/gold-plugin.cpp >> >> // ParseCommandLineOptions() expects argv[0] to be program name. >> Lazily >> >> cl::ParseCommandLineOptions(NumOpts, &options::extra[0]); > > > That is for the options that the gold plugin itself doesn't un...

Well, although cl::ParseCommandLineOptions contains support for @file. By default it is disabled, which is the case for llvm-link. To enable @file support in llvm-link, a small change is needed: --- llvm-link.cpp.orig 2012-09-20 16:10:50.000000000 -0400 +++ llvm-link.cpp 2012-09-20 16:11:24.000000000 -0400 @@ -83,7 +83,7 @@ LLV...

...ferable 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'...

...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: > >...

Could we enable ReadResponseFiles=true by default? 2012/9/21 Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>: > Well, although cl::ParseCommandLineOptions contains support for @file. By default it is disabled, which is the case for llvm-link. > > To enable @file support in llvm-link, a small change is needed: > > --- llvm-link.cpp.orig 2012-09-20 16:10:50.000000000 -0400 > +++ llvm-link.cpp 2012-09-20 16:11:24.000000000 -0400 &g...

...llvmdev/2006-February/005246.html) I was getting a error if I used -L switch when linking using the following command line: llvm-ld -o t1.app t1.bc t1.a -L/opt/llvm-1.6/llvm-gcc/lib -lcrtend I believe I've tracked down the problem; in the "main" of tools/llvm-ld.cpp the call to ParseCommandLineOptions is after the TheLinker.addPaths(LibPaths) statement so the -L command line parameter is ignored. My fix was to move the ParseCommandLineOptions to the beginning of the main routine. Cheers, Wink Saville

...ant to expose to users and the ones which we use for >> testing llvm itself. The options we want to expose should be just >> constructor arguments. With that distinction we should be able to just >> not use the options added by cl::OptionRegistry::CreateOption unless >> cl::ParseCommandLineOptions is called. WebKit like clients would just >> not call cl::ParseCommandLineOptions. Would that work? >> >> >> This is actually how some of our internal clients are already working. There >> are a few caveats with this approach: >> >> (1) You can’t allow t...

...umber of instructions to scan in a block in memory " 00058 "dependency analysis (default = 100)")); The args can be changed using opt, but we are using libclang and libllvm and running pass with llvm passmangers. I know that -mllvm can pass llvm args, but the llvm::cl::ParseCommandLineOptions has some issues with mutlethread and I have reported a bug in https://llvm.org/bugs/show_bug.cgi?id=25735, and we could not use this for now. So if there is another way to pass this memdep-block-scan-limit into the pass manager or context? Or how could I set this memdep-block-scan-limit right w...

...option a flag. One flag could be for llvm options, another for hidden llvm options and one for my application (if llvm uses 2 there are 30 left ;-). These flags could replace the hidden and "really hidden" states. Options would be hidden if their flag is not set in an int passed to cl::ParseCommandLineOptions (perhaps 2 sets of flags, one for -help and one for -help-hidden). Another possibility would be to specify the list of registered options explicitly for each of my options (default is the static one in CommandLine.cpp) and this could be passed to cl::ParseCommandLineOptions. -Jochen

...e... int llcmain(int argc, char **argv) { ... } ...to... extern "C" int llcmain(int argc, char **argv) { ... } Now I am calling this function directly from my server code. This works fine for the first build, however any other builds fail in CommandLine.cpp:1101 CommandLineParser::ParseCommandLineOptions assert(hasOptions() && "No options specified!"); <--fails here I'm trying to work out why this is breaking, I am assuming there is some global state left after processing that llc.cpp doesn't normally need to worry about? Is there a way to reset this global state cl...

...and line options? >> 3. Where should the command line options or module/function attributes be stored once they are read out from the IR? >> >> The short description of the approach I took in my patch is that command line options that are important to codegen are collected by cl::ParseCommandLineOptions, written to the bitcode as function or module attributes, and read out directly by the optimization passes that need them. cl::opt options are replaced with CodeGenOpt options (subclass of cl::opt), which are needed only to parse the command line and provide the default value when the corresponding...

...nes which we use for >>>> testing llvm itself. The options we want to expose should be just >>>> constructor arguments. With that distinction we should be able to just >>>> not use the options added by cl::OptionRegistry::CreateOption unless >>>> cl::ParseCommandLineOptions is called. WebKit like clients would just >>>> not call cl::ParseCommandLineOptions. Would that work? >>>> >>>> >>>> This is actually how some of our internal clients are already working. There >>>> are a few caveats with this approach:...