similar to: [LLVMdev] how to disable command line options in llvm libs

On Sat, Oct 9, 2010 at 7:59 AM, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote: > 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. I've always found

> 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

Now I have -DLLVM_INCLUDE_EXAMPLES:BOOL=OFF but Kaleidoscope is still there and selected for build (-G "Visual Studio 9 2008") -Jochen

On Sun, Jun 7, 2009 at 1:48 AM, Paul Melis<llvm at assumetheposition.nl> wrote: > Hello, > > Is there currently a way to set options, like -time-passes or -regalloc > from C++? I looked at the code in lib/Support/CommandLine.cpp, but the > stuff that comes closest to providing such functionality (mostly > GetOptionInfo()) is marked static. You can manipulate the

> On Aug 18, 2014, at 4:25 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > >> On Aug 18, 2014, at 3:21 PM, Chris Bieneman <beanz at apple.com> wrote: >> >> >>>> On Aug 18, 2014, at 3:09 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>>> >>>> Some passes take options directly in the

> On Aug 18, 2014, at 2:42 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > On 18 August 2014 14:49, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> Today command line arguments in LLVM are global variables. An example >> argument from Scalarizer.cpp is: >> >> static cl::opt<bool> ScalarizeLoadStore

Hi! is it possible to build only the libs (and no executables) with cmake? I already have LLVM_BUILD_TOOLS:BOOL=OFF and CLANG_BUILD_EXAMPLES:BOOL=OFF but things like Kaledoscope are still built. -Jochen

> On Nov 14, 2014, at 2:44 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > +chrisb > >> On 2014-Nov-13, at 16:33, Akira Hatanaka <ahatanak at gmail.com> wrote: >> >> I'm working on fixing PR21471, which is about embedding codegen command line options into the bitcode as function or module-level attributes so that they don't get

Hi! > sin/cos etc should already be handled by lib/Analysis/ConstantFolding.cpp. > Thanks for the hint and it works! Now I have a new Problem: I have this function: float foo(float a, float b) { float x = a * b * 0.0f; return cos(0.5) * sin(0.5) * x; }; after compiling it with clang (cpp mode) and renaming _ZSt3sinf to sin and _ZSt3cosf to cos I get the following: define

Hi all, I am experiencing a problem managing the command line option of a set of passes in my LLVM project. Attached you find a toy project the triggers the problem. The project is made up of two passes: "AnalysisPass" and "TransformPass". "TransformPass" requires "AnalysisPass" and they both share a common integer command line option called

Updated patch is attached. Note this is just a work-in-progress patch and I plan to address the feedback comments later if this patch is in the right direction. This is how the command line options are parsed and used by the backend passes: 1. Tools such as clang and llc call cl::ParseCommandLineOptions. Any of the options that should be written to the bitcode as function or module attributes

Hi, I am running a server that does regular builds using llc. To begin with I was doing a fork/exec to launch llc, passing the files to compile and other switches as command line, etc. then waiting for the subprocess to complete. This was fine but seemed an unnecessary overhead. After all llc is mostly a fairly thin front end over the llc libraries, which do the actual work right? So I took

There are parts of this proposal that I really like, and there are others that I think are actually at opposition to the work we’re trying to do with cl::opt. > On Nov 14, 2014, at 2:44 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > +chrisb > >> On 2014-Nov-13, at 16:33, Akira Hatanaka <ahatanak at gmail.com> wrote: >> >> I'm

Hi! Of course nobody wants to implement unicode support for windows because windows should support an utf8-locale and windows is obsolete anyway ;-) But there is a simple solution: use boost::filesystem::path everywhere you use file names and paths, for example in clang::FileManager::getFile. With version 3 opening a file is easy: std::fstream file(path.c_str()). Internally

Hello, Is there currently a way to set options, like -time-passes or -regalloc from C++? I looked at the code in lib/Support/CommandLine.cpp, but the stuff that comes closest to providing such functionality (mostly GetOptionInfo()) is marked static. Thanks, Paul

Is anyone currently working on overhauling the command-line processing code? We're currently having some design issues with this component, and I'd like to start a larger conversation on it. For context, I am talking from an "LLVM as a library" perspective instead of an "LLVM as a set of tools" perspective. In a nut-shell, the problems we are facing are as follows:

Hi all, I'm porting some LLVM plugins to the new pass manager and I've noticed that the command line options are no longer registered when using `-load-pass-plugin` (the new PM flag) to load the plugins in opt. Everything is back to normal when loading via `-load` (the legacy PM). For example, given this CL option: static cl::opt<bool> SomeFlat("some-flag",

>> Now I'm using LLVM_BUILD_EXAMPLES=OFF and I have >> >> //Build LLVM example programs. >> LLVM_BUILD_EXAMPLES:BOOL=OFF >> >> in the cmakecache.txt file but it also does not seem to >> work. >> > > What that means? LLVM_BUILD_EXAMPLES shall create build targets for the > examples but do not build them when you build the ALL_BUILD

On Wed, Nov 19, 2014 at 3:28 PM, Eric Christopher <echristo at gmail.com> wrote: > So my general concern here is that lots of command line options that don't > need to be or shouldn't be IR level constructs become oddly named string > options. It's bad enough that we're doing that with the target cpu and > target feature string let alone the rest of it. > >

On 25.11.2010 23:56, Michael Spencer wrote: > On Nov 25, 2010, at 5:01 PM, Jochen Wilhelmy <j.wilhelmy at arcor.de > <mailto:j.wilhelmy at arcor.de>> wrote: > >> Hi! >> >> Of course nobody wants to implement unicode support for windows >> because windows should support an utf8-locale and windows is obsolete >> anyway ;-) >> >> But