search for: zeroormor

All, Is there any particular reason we don't use cl::ZeroOrMore more pervasively with the cl::opt class of command-line options? 1. Some of llvm's optimizations are enabled/disabled by llvm command-line options. Passing these options to our build system via CFF and CXXF result in redundant CL options. If the CL option is a cl::opt which defaults to cl::...

...common.rng --- src_clean/docs/schemas/domaincommon.rng 2015-01-23 06:46:24.000000000 -0500 +++ src/docs/schemas/domaincommon.rng 2015-03-10 11:30:42.057441342 -0400 @@ -4468,6 +4468,7 @@ <data type="NCName"/> </attribute> <optional> + <zeroOrMore> <element name="parameter"> <attribute name="name"> <ref name="filter-param-name"/> @@ -4476,6 +4477,7 @@ <ref name="filter-param-value"/> </attribute> </element&...

...xternal code. For example dragonegg does #include "llvm/Support/PluginLoader.h" This file contains // This causes operator= above to be invoked for every -load option. static cl::opt<PluginLoader, false, cl::parser<std::string> > LoadOpt("load", cl::ZeroOrMore, cl::value_desc("pluginfilename"), cl::desc("Load the specified plugin")); If dragonegg is compiled with RTTI then linking fails because there is no RTTI for the cl::opt class. Thus dragonegg is forced to compile with -fno-rtti if it wants to work with this part...

....cpp b/lib/RegisterPasses.cpp > index 7fc0960..2e25e4d 100644 > --- a/lib/RegisterPasses.cpp > +++ b/lib/RegisterPasses.cpp > @@ -125,28 +125,34 @@ static cl::opt<bool> DeadCodeElim("polly-run-dce", > cl::Hidden, cl::init(false), cl::ZeroOrMore, > cl::cat(PollyCategory)); > > -static cl::opt<bool> > +bool polly::PollyViewMode; > + > +static cl::opt<bool, true> > PollyViewer("polly-show", > cl::desc("Highlight the code regions that will be...

Hi Tobias, I have attached a patch file to optimize string operations in Polly-Detect pass. In this patch file, I put most of long string operations in the condition variable of "PollyViewMode" or in the DEBUG mode. Bests, Star Tan At 2013-07-22 22:27:48,"Tobias Grosser" <tobias at grosser.es> wrote: >On 07/22/2013 01:46 AM, Star Tan wrote: >> At

...egg does > > #include "llvm/Support/PluginLoader.h" > > This file contains > > // This causes operator= above to be invoked for every -load option. > static cl::opt<PluginLoader, false, cl::parser<std::string> > > LoadOpt("load", cl::ZeroOrMore, cl::value_desc("pluginfilename"), > cl::desc("Load the specified plugin")); > > If dragonegg is compiled with RTTI then linking fails because there is no RTTI > for the cl::opt class. Thus dragonegg is forced to compile with -fno-rtti if > it wants...

On 07/22/2013 01:46 AM, Star Tan wrote: > At 2013-07-22 12:16:53,"Tobias Grosser" <tobias at grosser.es> wrote: >> I propose two more patches: >> >> 1) Transform the INVALID macro into function calls, that format >> the text and that set LastFailure. > Translating the INVALID macro into function calls would complicate the operations for

Luba Tang <lubatang at gmail.com> writes: > We found `llvm-config --cxxflags' does not have -fno-exceptions -fno-rtti > when using cmake to build LLVM. > Does anyone know how to fix it? Using -fno-rtti and -fno-exceptions is an internal LLVM policy. There is no reason to impose it on client code.

...ass object. I tried the following code (which I wrote after looking at the code for bugpoint), but the list of passes seems to be empty: // Create a list of all the registered passses static cl::list<const PassInfo*, bool, PassNameParser> PassList(cl::desc("Passes available:"), cl::ZeroOrMore); mem2reg_pass = NULL; for(It i = PassList.begin(); i != PassList.end(); i++) { std::cout << (*i)->getPassName() << endl; if(string("mem2reg") == (*i)->getPassName()) { mem2reg_pass = *i; break; } } assert(mem2reg_pass); assert(mem2reg_pass->g...

...de "llvm/Support/PluginLoader.h" >> >> This file contains >> >> // This causes operator= above to be invoked for every -load option. >> static cl::opt<PluginLoader, false, cl::parser<std::string> > >> LoadOpt("load", cl::ZeroOrMore, cl::value_desc("pluginfilename"), >> cl::desc("Load the specified plugin")); >> >> If dragonegg is compiled with RTTI then linking fails because there is no RTTI >> for the cl::opt class. Thus dragonegg is forced to compile with -fno-rtti...

On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote: >> That should work fine, just use "jit" instead of "x86-emitter" as the >> debug type. > > That's impossible: CurrentDebugType is now private; it appears > nowhere in the installed headers. I can't find any public interface > to allow a JIT to set it. Ah ok. I'd suggest doing what llvm-gcc

Is it possible to unroll a loop (forcibly if necessary) with llvm (possibly the -loop-unroll pass) a constant number of times. I believe that I read that the -unroll-count=x option was removed, correct? So is there some other way to do this or is this just not possible in llvm? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, We found `llvm-config --cxxflags' does not have -fno-exceptions -fno-rtti when using cmake to build LLVM. Does anyone know how to fix it? Best regards, Luba ---------- Forwarded message ---------- From: Luba Tang <lubatang at gmail.com> Date: 2012/11/21 Subject: Re: [MCLinker] Re: Major release - MCLinker 2.0.0 - RockBull To: mclinker at googlegroups.com Hi, We make sure the

Chris Lattner wrote: > On Jan 20, 2009, at 2:10 AM, Andrew Haley wrote: > >> Chris Lattner wrote: >>> On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote: >>> >>>> This is x86_64. I have a problem where an absolute memory load >>>> The current LLVM trunk does not have this bug. This seems quite a >>>> nasty >>>> bug; is

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached