similar to: [LLVMdev] patch to enable response file support in ParseCommandLineOptions

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

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 > +++

I have no objection to that. Actually I am curious why it is disabled by default. If we enable ReadResponseFiles=true by default, we will automatically get support of response file (@file) in all llvm tools. The only issue I can think of is that some users may have file names starting with "@". Sam -----Original Message----- From: NAKAMURA Takumi [mailto:geek4civic at gmail.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 @@ -83,7 +83,7 @@ LLVMContext &Context = getGlobalContext();

Response file is the conventional name for files serving this purpose. A google search shows the usage of "response file" is not rare. Also it has been used in the LLVM documentation: http://llvm.org/docs/CommandLine.html#response-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)

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 enables response > file support and removes the argument for controlling/disabling response >

Thanks Chris for the comment. Since there is no objection, I attached a new patch which enables response file support and removes the argument for controlling/disabling response file support. The patch also contains 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:

The motivation 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

I don't have any opinions about this. Chris? Evan On Feb 17, 2009, at 8:00 PM, Alexei Svitkine wrote: > The motivation 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

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?

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

On 21 September 2012 10:44, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > I have no objection to that. Actually I am curious why it is disabled by default. > > If we enable ReadResponseFiles=true by default, we will automatically get support of response file (@file) in all llvm tools. The only issue I can think of is that some users may have file names starting with

Sent from my iPhone > On May 30, 2016, at 4:52 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> On 30 May 2016 at 16:56, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >> >> 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

I like your predicate idea - that could solve both #1 and #2. I'm wondering whether it would be possible to get the predicate stuff automatically somehow - based on which library an option is coming from. Something like looking at the path in __FILE__. Then we could simply enable/disable any options based on their library of origin (i.e. as in, one of the --libs out of llvm-config --libs).

Hello, As previously mentioned I had a linking problem using llvm-ld (http://lists.cs.uiuc.edu/pipermail/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

On Jan 16, 2013, at 10:32 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > Hello, > > When someone breaks a FileCheck-based test on some buildbot, sometimes > it may not be obvious *why* did it fail. If the failure can not be > reproduced locally, it can be very hard to fix. > > I propose adding a "very verbose" mode to FileCheck. In this mode >

> On Aug 18, 2014, at 3:09 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> Some passes take options directly in the constructor. For example >> >> Inliner::Inliner(char &ID, int Threshold, bool InsertLifetime) >> >> Maybe we could just say that there are two different types of options. >> The ones we want to expose to users

Hi! I'd like to use llvm::cl as it seems quite easy to use, but there currently seems to be a major drawback: if I do -help then all options from all llvm libs that I have included are shown, but I just have an input file and output file to specify. Is it possible to disable the existing options? For example by assigning each option a flag. One flag could be for llvm options, another for

On Thu, Jan 17, 2013 at 1:19 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Wed, Jan 16, 2013 at 9:33 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> On Wed, Jan 16, 2013 at 9:24 PM, Chris Lattner <clattner at apple.com> wrote: >>> >>> On Jan 16, 2013, at 10:32 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >>>

Hello, We are now facing a bug caused by the GVN pass, only part of the code was optimized. I have found that the problem is cause by an Limit in lib/Analysis/MemoryDependenceAnalysis.cpp 00055 static cl::opt<unsigned> BlockScanLimit( 00056 "memdep-block-scan-limit", cl::Hidden, cl::init(100), 00057 cl::desc("The number of instructions to scan in a block in